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.
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
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
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
Workspace usage statistics
Improvements to workspace usage statistics
Better workspace cleanup management, e.g. matrix workspaces cleanup JENKINS-27329
Skills: Java, Cloud-based storage
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.
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.
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)
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…
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
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:
Determine a list of builds to discard by looking at the build history of a given project.
Perform the discard actions on the builds that were made elements of the list of builds to discard.
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.
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:
New plugin for integration with various external tools or services (e.g. plugins for Electronic Design Automation Tool proposal)
Working on major feature requests from the Jenkins bugtracker
Creating new demo and reference setups, powered by various "-as-Code" engines (e.g. Jenkins Pipeline, JobDSL, Docker, Configuration-as-Code plugin, etc.)
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.
Although we encourage students to propose their own project ideas, we cannot guarantee that will find potential mentors for every proposal, especially for narrow areas. During the selection phase we won’t be able to accept proposals without mentors, so we highly recommend getting initial feedback in the mailing lists before spending too much time on such proposals.