GSoC 2018 Project Ideas

Jenkins GSoC

This page aggregates project ideas for Google Summer of Code 2018. See more information about this project and applications at the project’s page.

Below you can find project ideas proposed by potential mentors. Other ideas may be proposed by students (e.g. new features in the core, "write a plugin for MY_TOOL_OR_SERVICE", etc.). Such project applications will be considered though applicants may need to work with the community and GSoC admins to find potential mentors.

Jenkins Configuration as Code

Configuration-as-Code plugin has been designed as an opinionated way to configure Jenkins based on human-readable declarative configuration files (YAML). Plugin should be easy to use regardless of previous Jenkins experience or Jenkins model expert knowledge. This will allow to fully automate Jenkins deployment process and manage Jenkins (one or multiple instances) configuration.

We want to release plugin before summer, so the project would be a number of improvements and integrations on the top of the core features. The potential tasks would be to provide support for various plugins to make them compliant with Configuration-as-Code. Also you can work on more advanced Plugin features, like exporting configuration of an existing Jenkins Instance to YAML files.

Skills: Java, Docker

Potential mentors: Ewelina Wilkosz, Thorsten Höger

Jenkins Remoting over Message Bus/Queue

Current versions of Jenkins Remoting are based on the TCP protocol. If it fails, the agent connection and the build fails as well. There are also issues with traffic prioritization and multi-agent communications, which impact Jenkins stability and scalability.

This project aims an update of Remoting and Jenkins in order to add support of a popular message queue/bus technology (RabbitMQ, ActiveMQ, etc.) as a fault-tolerant communication layer in Jenkins.

Skills: Java, Networking, Message queues

Potential mentors: Oleg Nenashev, Willy Aguirre

Cloud Features for External Workspace Manager Plugin

We wish to add Cloud features to the Jenkins External Workspace Manager Plugin.

This would allow Jenkins workspaces to be cloud based or located remotely, rather than being local. These features include:

  • Cloud-based storage support (discussion)

  • Support use of multiple discard strategies

  • Integration with the core’s “Discard old builds” feature

  • Improvements to data retention policies (e.g. JENKINS-48715, JENKINS-2111, JENKINS-38764)

  • Workspace usage statistics

  • Improvements to workspace usage statistics

  • Better workspace cleanup management, e.g. matrix workspaces cleanup JENKINS-27329

Skills: Java, Cloud-based storage

Potential mentors: Martin d’Anjou, Oleg Nenashev

Role Strategy Plugin performance and/or user experience

Role Strategy Plugin is widely used in Jenkins as an authorization engine, but it has known performance limitations for large-scale setups. In this project the proposal is to improve the plugin’s performance and to create a proper testing framework for Jenkins security plugins. Web interfaces of this plugin can be also improved.

Skills: Java, performance testing, profiling tools, JavaScript (for UX part)

Potential mentors: Oleg Nenashev, Steven Christou

Plugin(s) for Electronic Design Automation tools

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, FuseSoC, ArachnePnR, icetools), but we also consider conditionally-free tools (like FPGA design EDAs).

Examples of tool integration:

  • Tool launch and publishing steps for Free-style and/or Pipeline jobs

  • Integration with Warnings Plugin for report parsing.

  • Reporting of FPGA resource utilization (per build + trends)

  • Timing report trend publishing

  • Integrating UVM reports into Jenkins build and project pages

Skills: Jenkins as a user, Java

Special requirements: In the case of FPGA tools integration, a prototyping board will be required.

Potential mentors: Martin d’Anjou, Oleg Nenashev

Code Coverage API Plugin

There are a lot of plugins which currently implement code coverage (clover plugin, cobertura plugin, clover php plugin, etc), however they all are using similar charts and similar content. Instead of having one plugin for each code coverage result it would be best if we could merge them all into one plugin which will handle code coverage.

Most code coverage results display similar content like: File Name, Lines covered, Methods covered Branches covered, Red/Green/Yellow statuses, Coverage over multiple builds, etc.

Skills: Java, HTML/CSS (possibly)

Potential mentors: Steven Christou, Jeff Knurek

Simple Pull-Request Job Plugin

Pull-Requests are the de facto standard for accepting changes into upstream repositories. The idea is to create a new Pull Request job type which can be configured by a YAML file in the root directory of the Git repository being the subject of the PR. It can be done by creating a new plugin or by extending existing ones

Jobs of this type could be coded using the Jenkins DSL and the Pipeline shared libraries. The benefit of turning this pattern into a plugin is that users no longer need to craft `Jenkinsfile`s on their own. This type of simplicity exists for example with the Travis PR builder.

Additional features can be added once the basics are in place. For example:

  • selection of workspace type (internal or external)

  • build status updates to git servers

  • notifications (email, other)

Being compared to existing plugins, this plugin does not create jobs and does not detect branches automatically. The users are responsible for creating the jobs they need. This type of jobs have to be triggered via the existing methods (e.g. an http post to the Jenkins REST API, or via the UI). More details…​

Skills: Java

Potential mentors: Martin d’Anjou, Willy Aguirre

Improvements to the Jenkins Acceptance Test Harness

The Jenkins Acceptance Test Harness (ATH) is a great vehicle to test Jenkinsfiles and custom DSL libraries ahead of deploying them to production servers. However, it has couple of drawbacks.

  • it can be quite slow as it needs to bootstrap an entire Jenkins instance for each test method.

  • real production environments typically need to use a very specific plugin list of pre-defined plugins and plugin versions

Improving these two areas would make the ATH more efficient and easy to use for Jenkinsfile and custom DSL library testing.

For example, instead of dynamically creating a Jenkins instance for each test, an instance could be built as a docker image, loaded as a java testcontainers, and injected with the DSL to be tested.

Skills: Java, Selenium, Docker

Potential mentors: Martin d’Anjou, Steven Christou

Other project ideas

In addition to the finalized project ideas, we also have some draft ones in this document. If you are interested, feel free to comment in the document or to add your own ideas there.

Draft ideas under discussion:

Proposing new project ideas

New ideas can be proposed by mentors and/or students. Please add your ideas to this document for further discussion.