Jenkins : GSoC 2016. Student Application Phase

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!