Jenkins : Google Summer Of Code 2016

Jenkins project participated in the Google Summer Of Code 2016 (GSoC) as a part of the ongoing Jenkins 2.0 activities.
This page describes the information from the Student application phase from this year.

See the project results and info about other years on

Goalsthe Jenkins Website

We want to focus on all kinds of User Experience in Jenkins core, its many plugins, and the project infrastructure

  • Yes, we want to make Jenkins users happy
  • "User Experience" does not mean "User Interface" only
  • We also consider projects addressing availability issues and new Jenkins usage scenarios (e.g. Pipeline-as-code)


A few quick Jenkins facts for newcomers:

  • Jenkins, originally founded in 2006, is one of the leading automation servers available
  • With an extensible, plugin-based architecture, developers have created over 1000 plugins to adapt Jenkins to various build, test, and deployment automation workloads
  • There are over 120,000 active Jenkins installations, running on over 420,000 machines

You can learn more about how we work in the Governance Document, and get a few more facts on the Jenkins Organisation Page on the GSoC website.

Project ideas

The table below shows a list of detailed project ideas. See also the additional project areas below the table.

Well-defined project ideas



Potential mentors


Jenkins Web Interface Improvements

Core, Plugins

Unknown User (michaelneale), Unknown User (tfennelly), Unknown User (oleg_nenashev)

As a part of 2.0 UX improvements we want to improve Jenkins WebUI. There are many potential improvements, which have been rejected due to the limited resources. In this project we propose to select particular Jenkins UI components from Jenkins core or plugins, and then to improve them by using new approaches or technology stacks. Requirements:

  • Basic knowledge of HTML and CSS
  • Nice2have: experience with JavaScript (especially ReactJS or Node.js)

Update Center 2.0

Core, Project infrastructure

Unknown User (batmat)Unknown User (abayer)

Improvement of the current Plugin Manager UX + associated infrastructure changes/improvements.
Currently, it's for example a bit complicated to switch from the main update center URL to the experimental one. Have a reputation system on plugins, and so on.
Also, after discussing plugin origin requirements, we've been proposing to actually have many update centers directly visible (be it in a tab, or something), and users could choose in a clearer way to choose to install a "non-official" plugin, but still make it an easy task.

  • Basic knowledge of HTML and CSS
  • Nice2have: experience with JavaScript (especially ReactJS or Node.js)
  • Basic knowledge of Java (and ideally Groovy)

New generation of Fingerprinting engine for Jenkins


Unknown User (oleg_nenashev)

Improvement of Jenkins Fingerprinting engine. It is a proposal for Jenkins 2.0, which is described here (summary presentation). The scope for the student project is TBD, but the entire implementation can be done by a group of 2-3 students. In general, there are 3 potential project areas:

  • UX/UI improvements for the existing functionality
  • Fingerprint architecture rework for a better extensibility
  • Backend data storage: extensibility, support of external databases as a storage
  • Basic knowledge of Jenkins (as a user)
  • Basic knowledge of Java programming language

Integration of Docker plugins with Jenkins 2.0 features like Pipeline as Code


Unknown User (ndeloof) and Unknown User (ydubreuil)

Offer a Pipeline command syntax to run pipeline steps inside docker containers, the same way pipeline do support `node()`. Plan to rely on plain docker CLI, to avoid dependency on Jenkins slave remoting in docker images. Prerequisites:

  • Basic knowledge of Java
  • Basic knowledge of Docker

Plugins for EDA and Embedded Dev. tools integration


Unknown User (oleg_nenashev), Unknown User (deepchip)

The idea is to create a Jenkins plugin for one of widely used EDA tools. Both ASIC or FPGA design flow are acceptable, the tool should be proposed by the potential student. Open-source EDA tools would be preferable (e.g. Yosys, ArachnePnR, icetools), but we also consider conditionally-free tools (like FPGA design EDAs). Prerequisites:

  • Basic knowledge of Jenkins (as a user)
  • Basic knowledge of Java programming language
  • Hands-on experience with the selected EDA tool. In the case of FPGA flows it would be useful to have a prototyping board as well.

Automatic plugin documentation publishing on

Website, Project infrastructure

Unknown User (rtyler), Unknown User (orrc)

Jenkins projects has currently the plugin documentation is being stored in Confluence. Sometimes the documentation is scattered and outdated. In order to improve the situation we would like to follow the documentation-as-code approach and to put docs to plugin repositories and then publish them on the project website using the awestruct engine. The project aims an implementation of a documentation continuous deployment flow powered by Jenkins and Pipeline Plugin. Requirements:

  • Experience with Asciidoc, Markdown or Tex documentation formats
  • Basic knowledge of Git SCM and its command-line tools
  • Ruby programming experience

Support core plugin improvements


Unknown User (aheritier), Unknown User (schristou)

It is often difficult for plugins developers to diagnose issues and analyse the user environment.

The support core plugin allows users to generate a bundle to help on this but it is nowadays rarely used because it is isn't user friendly.
Various fixes and improvements ('support-core-plugin') may help a lot our community. Few ideas of new features to add:

  • Ease the management of bundles (UI to list, delete, browse, download bundles) - JENKINS-33090
  • Bundles will have to be stored in our public JIRA thus it is critical to provide anonymisation of the content by default - JENKINS-21670
  • Submission of bundles in our bug tracker ( - JENKINS-33091
  • ... 

  • Basic knowledge of Jenkins (as a user)
  • Basic knowledge of Java programming language

External Workspace Manager plugin development


Unknown User (deepchip), Unknown User (oleg_nenashev)

Some compilers generate very large volumes of output artifacts, both in file size and quantity of files (e.g. EDA compilers). Currently, sharing this data between builds is done by copying files rather than reusing the build workspace, but this approach is not efficient and can be slow. The proposed External Workspace Manager plugin aims to facilitate the reuse of workspaces between builds.

  • Basic knowledge of Java or Groovy programming language, including unit testing
  • Basic knowledge of writing your own Jenkins plugin (jelly, pom.xml), or strong willingness to learn how to do it (mentoring and example are available).

Usage Statistics Analysis

Project infrastructure

Unknown User (kohsuke),
Unknown User (danielbeck)

Jenkins project has collected anonymous usage statistics from more than 100,000 installations around the world, which includes such information like the size of the deployment, a set of plugins and their versions, and a bunch more. We currently only use it to visualize this data somewhat crudely

There are several very different ways to slice this project:

  • Visualize data in more viewer friendly way. Prettier/better graphs, CSV output.
  • Mine this data further. This is really open-ended with tons of possibilities. For example, if we can tell what plugins are likely used together, our update center can use this information to recommend plugins. Or maybe we can tell when downgrades are happening, and that can work as a warning that something is wrong with that version
  • Improve the realtime-ness of the data processing. Instead of doing this every month, can we create a moving 4 week window and analyze data so that we get more live data?

    Data science is a hot field, and I think this experience will set you up well for your future careers!

Other ideas

The list above is not final. Students are eligible to propose any Jenkins-related ideas. Various raw ideas can be found using via the list and links below:

For interested students

As per the GSoC timeline, applications will be open from March 14th until the 25th.

Student office hours

We will be holding a special set of GSoC office hours where interested students can discuss with potential mentors from the Jenkins project.

All events will take place via this Google Hangouts link: — during these timeslots Jenkins GSoC admins and mentors will be also available on the #jenkins IRC channel.

Student applications

In the meantime, if you are interested in working with Jenkins during GSoC, please follow these guidelines:

In order to register your interest, please use the jenkinsci-dev Google group. Please note that this list is publicly visible inside and outside the community. It is required for the initial review and feedback collection.


  • You must join the jenkinsci-dev Google group
  • You must have an account on GitHub

Recommendations for your first email to jenkinsci-dev:

  • Please use the "[GSoC2016] -" prefix in your message subject
  • In the first e-mail we would be interested to see the following information:
    • A short self-introduction: your area of study, interests, background
    • Motivation letter. Why are you interested in the Jenkins project? On which project areas would you like to work? If there are particular proposals, please let us know about them as well, and any initial thoughts on why you would be suited
    • If you participate in open-source projects, please reference them
    • If you have profile pages in professional networks like LinkedIn, please reference them
    • If you have a Twitter account, a blog or technical/scientific publications, please refererence them as well

Getting in touch

If you have any questions during the application process, please feel free to contact us via the #jenkins IRC channel or the mailing list.

Organisation admins

Organisation admins are people from the Jenkins project responsible for managing the GSoC process, and further collaboration between the Jenkins project, SPI and Google.


Below you can find a list of people, who agreed to be mentors:

For mentors

Mentorship rules

We will appreciate mentorship provided by any Jenkins contributor. On the other hand, we want to avoid any conflicts with GSoC explicit and implicit rules. We also want to avoid conflicts of interest between all sides.

  • Only an individual contributor may be a mentor
  • All mentors and org admins are considered as Jenkins community representatives. They must follow the Code of Conduct
  • If a mentor works for a company, which use Jenkins in commercial products...
    • The mentorship work should be performed during spare time or during the OSS contribution time dedicated by the company. In the last case the mentor should ensure that there will be a consistent time dedicated over the entire GSoC mentorship period
    • The project proposed by mentors should not overlap neither with direct responsibilities within the company nor with the company product roadmaps.
    • He(she) should ensure there is no conflict of interest between the project and the work responsibilities

There are several examples below:

  • "I would like to have this feature in my Jenkins installation. I have already made a commitment to deliver within my company. I will lose my bonus if I fail the commitment"
    • NOT FINE, you have a conflict of interest. GSoC project may fail due to many reasons
  • "I would like to have this feature in my Jenkins installation. It would provide us some added value, but we can live without it. I have not made any commitments"
    • FINE if the proposed project is useful to a significant part of the community. Added value will keep you motivated
  • "This feature has been already announced publicly by my company, we want to ship it as a part of our product"
    • NOT FINE, you have a conflict of interest
  • "This feature has not been announced publicly by my company, but we will do it after GSoC"
    • NOT FINE, you have a conflict of interest
  • "Our product may benefit from the feature, but it's not in our roadmaps. The project idea is useful to the community"
    • PROBABLY FINE, consult with GSoC Org Admins
  • "I want to mentor this feature, but I see that somebody works on the similar feature in open-source"
    • PROBABLY FINE, consult with the developers of the competing solution. Try to join forces and get them as mentors.
  • "I want to mentor this feature, but I see that another company provides a similar closed-source solution"
    • FINE, but ask GSoC Org Admins to contact company. Maybe they agree to open-source it (and to assign a mentor). If no, it's their problem.
  • "I want to implement a feature based on a patented algorithm/technology. It's open-source, so we are free to do whatever "
    • NOT FINE, Jenkins project recognizes laws. We are under umbrella of Software In Public Interest organization, which is a subject for US and international legislation. Contact the patent holder to get a license (needs a review by Jenkins Governance meeting).
  • "I went through the list and still have concerns"
    • PROBABLY FINE, contact GSoC Org Admins (

All potential issues should be escalated to GSoC admins. Intentional violation of the rules above may be a subject for Code of Conduct violation process.


Here are some older links, relating to when Jenkins was applying to be a mentoring organisation.

  • Discussion in the mailing list:\!searchin/jenkinsci-dev/Summer$20of$20Code/jenkinsci-dev/D7ue7xuyOkw/aiFTEZDoDQAJ\|\!searchin/jenkinsci-dev/Summer$20of$20Code/jenkinsci-dev/D7ue7xuyOkw/aiFTEZDoDQAJ (\!searchin/jenkinsci-dev/Summer$20of$20Code/jenkinsci-dev/D7ue7xuyOkw/aiFTEZDoDQAJ)
  • Application draft (submitted on Feb 19th)