GSoC 2018 Project Ideas

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

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, Supun Wanniarachchi

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:

Skills: Java, Cloud-based storage

Potential mentors: Martin d’Anjou, Oleg Nenashev

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

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:

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

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, Supun Wanniarachchi

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:

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, Surya Gaddipati

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.

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

The idea behind this plugin is to give users more options to manage and implement a data retention policy that covers their build histories, artifacts and workspaces (internal and external). This responsibility typically falls on the shoulders of Jenkins administrators, but since projects can have unique data retention requirements, this responsibility should be with project contributors. This plugin would enable users to specify their own data retention policy via a Pipeline build step.

The current Discard Old Builds feature could be improved, however to use it one must resort to clicking buttons in the UI, which is not desirable in the context of configuration-as-code. Also, the plugin would offer features above and beyond the existing Discard Old Builds functionality.

The plugin would internally work in two phases:

This plugin would leverage and enhance the Run Selector Plugin for selecting builds to discard, and new code would be written to perform the data discard actions.

More information regarding this proposal is available here.

Skills: Java

Potential mentors Martin d’Anjou, in need of an additional mentor

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:

New ideas can be proposed by mentors and/or students. In order to propose a new project idea, create a draft description and start a new thread in the Developer mailing list (use the [GSoC] prefix in the email subject).

Need some hints? Here are examples of project ideas:

Once the project idea is proposed in the mailing list, GSoC org admins will help to finalize the idea and to reach out to potential mentors/co-mentors.