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)

Background

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

Title	Area	Potential mentors	Description
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	Core	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 Prerequisites: 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	Plugins	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	Plugins	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 https://jenkins-ci.org/	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	Plugins	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 (https://issues.jenkins-ci.org/issues/?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20'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 (https://issues.jenkins-ci.org) - JENKINS-33091 ... Prerequisites: Basic knowledge of Jenkins (as a user) Basic knowledge of Java programming language
External Workspace Manager plugin development	Plugins	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. Prerequisites: 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:

Ideas from Jenkins 2.0 discussions:
- Notes from Jenkins 2.0 contributor summit at FOSDEM. Many potential improvements are mentioned there (potential mentors - Unknown User (oleg_nenashev) and Unknown User (ndeloof))
- Jenkins 2.0 aggregated proposals
- Jenkins 2.0 proposals in JIRA
Update/rework of Jenkins core and plugin web interfaces
Remoting layer improvements (Unknown User (oleg_nenashev), TODO: slides)
Jenkins 2.0 website contribution (Unknown User (rtyler))
Test automation for Jenkins core and plugins (especially integration tests)
GitHub Plugin Release publisher (with ability to prepare drafts and upload artifacts) (Unknown User (lanwen))

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: https://jenkins-ci.org/hangout — during these timeslots Jenkins GSoC admins and mentors will be also available on the #jenkins IRC channel.

Monday March 7th - 9AM UTC for Asia/Oceania/Europe (Unknown User (oleg_nenashev) to host it)
Monday March 7th - 8PM UTC for US/Europe (Unknown User (rtyler) to host)
Wednesday March 9th - 7PM UTC during the regularly scheduled Jenkins Office Hours timeslot (Unknown User (oleg_nenashev), Unknown User (rtyler))
Thursday March 17th - 9AM UTC for Asia/Oceania/Europe (Unknown User (oleg_nenashev) to host it)
Thursday March 17th - 8PM UTC for US/Europe (Unknown User (oleg_nenashev) to host)
Sunday March 20th - 9AM UTC for Asia/Oceania/Europe (Unknown User (oleg_nenashev) to host it)
Sunday March 20th - 8PM UTC for US/Europe (host - TBD)
Wednesday March 23th - 8PM UTC for all (host - Unknown User (oleg_nenashev))

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.

Prerequisites:

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.

Links

GSoC guide for students: http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/
Application guidelines on the GSoC website.
GSoC timeline
Jenkins Dev 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.

Mentors

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

Unknown User (ndeloof) and Unknown User (ydubreuil) - Containerization: Jenkins and Docker OR Docker and Jenkins
Unknown User (oleg_nenashev) (GMT+1) - Embedded/HW/ComputingGrid plugins, remoting lib, fingerprint engine, Ownership Plugin and Custom Tools Plugin
Unknown User (batmat) - Update centers, project infrastructure
Unknown User (orrc) - Android, Website
Unknown User (rtyler) - Website, project infrastructure
Unknown User (aheritier) - Support plugin(s)
Unknown User (schristou) - Support plugin(s)
Unknown User (michaelneale) - UI Improvements
Unknown User (lanwen) - GitHub Plugin Release publisher, support plugins
Unknown User (kohsuke), Unknown User (danielbeck) - Jenkins usage statistics
Other mentors: need to get their final confirmation before listing

For mentors

Useful links

GSoC Mentor Guide: https://flossmanuals.net/GSoCMentoring/
GSoC timeline

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 (jenkinsci-gsoc-orgs@googlegroups.com)

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.