Jenkins in Google Summer of Code Midterm Recap

[amurleopard]

The Jenkins in GSoC program recently reached its midterm milestone for GSoC 2023. This milestone served to assess performance, and precipitate pass/fail decisions. Taking time to evaluate the progress and workflow of the project provides an opportunity to correct course and address underlying issues.

Earlier this month, on the Jenkins Online Meetup, GSoC contributors presented midterm status and progress for their projects, below is a recap. Thank you Jagruti, Harsh, Vandit, and Ashutosh for your contributions to Jenkins!

Add Probes to "Plugin Health Score"

By Jagruti Tiwari

A probe collects data about each plugin. It is an automated system that ensures the Jenkins Community-defined rules are followed. The probe data is used by health scoring to compute a score, and a higher-quality probe receives a good score. Conversely, an obsolete or outdated plugin is given a lower score.

Sharing details about the probes that I worked on during the first phase of GSoC.

Unreleased Production Changes Probe

A bug fix, security improvement, or new feature can only be beneficial when it’s actually released. The "Unreleased Production Changes" probe is designed to detect unreleased commits in the production files.

This probe’s primary goal is to identify unreleased production commits specifically in the Maven production files.

Following my mentors' advice, I began by writing test cases to accurately reproduce the probe’s requirements. Subsequently, I added the necessary code to pass each of these test cases.

During the implementation, I utilized the JGit library and familiarized myself with its features. However, I encountered some challenges due to a lack of depth in Git concepts, which required me to delve deeper and strengthen my understanding of Git concepts along the way.

Read the unreleased production changes blog post for more details on the probe.

The Third-Party Repository Detection Probe

By definition, a third-party repository is a repository that is not hosted at https://repo.jenkins-ci.org.

The third-party repository detection probe ensures that plugins are only built from trusted and reliable Maven repositories.

This probe was requested by the Jenkins community.

One of the major challenges in implementing this probe was considering the parent and child pom relationships from all angles.

Certain edge-case scenarios were not initially taken into account while specifying the probe, and due to the number of open questions, the probe was temporarily put on hold until further research was conducted.

Throughout the process, I extensively read the Maven documentation to gain a better understanding of how to test POM structure, inheritance, and Maven API.

Read the third party repository detection probe blog post for more details on the probe.

GitHub Security Scan Workflow Probe

The Security Scan probe identifies whether the plugin is configured to execute the security action.

From a security perspective, this probe is crucial as it checks for known security breaches and vulnerabilities in a plugin.

Its primary purpose is to ensure that the security scan is correctly configured in the plugin’s GitHub Action.

Additionally, this probe involves refactoring existing classes to avoid code duplication, and it shares similarities with the JEP-229 (Continuous Delivery) probe, which also looks for CI configurations in GitHub Actions.

Throughout this process, I have gained knowledge in leveraging the class hierarchy to build an abstract probe that can be implemented by any probes requiring GitHub Action configuration checks.

The findings of this probe will be highly beneficial to the security team, as it helps identify any gaps and enables the improvement of the overall security of the Jenkins plugin ecosystem.

Read the security scan probe blog post for more details on the probe.

What about the second-half of GSoC?

In the second half of the GSoC project, I will be working on a few more probes, including the following:

• Detect Renovate usage:

  • This probe will identify how many plugins use the Renovate bot CLI to detect outdated dependencies in the plugin.

  • If any outdated dependencies are found, it will automatically create a pull request (PR) to update the dependency.

• Count open tickets:

  • This probe will detect open issues in both Github and JIRA.

In addition to these new probes, I will also be focusing on fixing bugs and making enhancements to the existing probes.

GitLab Plugin Modernization

By Harsh Pratap Singh

The GitLab Plugin facilitates seamless interaction between Jenkins and GitLab. This project involves replacing the usage of the outdated RESTEasy library in the plugin with GitLab4J-API through the GitLab API Jenkins Library Plugin.

This migration holds significant importance for the following reasons:

1. The migration will significantly reduce future maintenance issues.

2. It makes the plugin more lightweight by reducing dependencies.

3. It improves consistency with other Jenkins plugins.

4. It enhances documentation and overall user experience.

During Coding Phase 1, the following achievements were made:

1. Successfully completed the migration from RESTEasy to GitLab4J-API via the GitLab-API plugin.

2. Conducted interactive testing of the partially migrated Plugin.

To use the upcoming modernized GitLab Plugin, please ensure the following requirements are met:

1. Minimum GitLab version: 14.0.

2. Minimum Jenkins version: 2.387.3.

Over the years, GitLab has evolved significantly. During the migration process, we discovered that the plugin will soon have the removal of GitLab API V3 support, as GitLab now only supports V4 of its API. We strongly encourage V3 users to switch to V4 as soon as possible.

The following tasks are still in progress during the 2nd Coding Phase:

1. Adapting the Webhooks to GitLab4J-API’s events (completed)

2. Migrating the Proxy settings

3. Adapting the unit and integration tests (work in progress)

4. Improving the documentation

Building Jenkins.io with Alternative Tools

By Vandit Singh

Jenkins users frequently refer to jenkins.io for documentation, and a new LTS line is released and available to all Jenkins users worldwide every 12 weeks. However, the documentation for each prior edition is not currently maintained, and that’s where my project comes in to provide Versioned Documentation for the users of the Jenkins community.

With my project, users will be able to switch between different versions of the documentation, depending on the version of Jenkins they are running. To achieve this, we adopt Antora, which comes with versioning out-of-the-box and creates documentation pages using asciidoc. Additionally, Gatsby will be used to generate some of the YAML file-generated components. This way, we aim to enhance the accessibility and usability of the documentation for Jenkins users.

Till now, we have migrated all documentation from jenkins.io which leaves us only with the Gatsby part of the implementation. The completed components include:

1. User Guide

2. Solution Pages

3. Tutorials

4. Developer Guide

5. Security

6. Subprojects

7. Community Section

With the successful migration of the above components, our next focus will be on working with the following components or single pages using Gatsby as the framework:

1. Blogs

2. Roadmap

3. Security Advisories

4. Download

5. Changelog

6. Upgrade Guide

7. About

8. Homepage

As we enter the 2nd Coding Phase of GSoC, completing these sections/pages will mark the end of the project and the full migration from Awestruct to Antora and Gatsby.

Docker-based Jenkins Quickstart Examples

By Ashutosh Saxena

The project’s goal is to address the problems and complexities users often face when setting up Jenkins with Docker. The current process involves multiple intimidating steps with security risks. So, how are we solving these problems?

The intimidating steps can be simplified by using Docker Compose to hide all the complexities of Docker. Additionally, we have created scripts to automate the running of the Jenkins container with Docker. One script is called jenkins_init.sh, and another script called jenkins_teardown.sh is used to clean everything.

To address the security risk of running jobs on the controller, we are using the controller and agent as separate containers. For this purpose, we use another script called keygen.sh that creates and updates SSH keys.

For the tutorial part, it is essential to lower the barrier to entry for Jenkins. Therefore, the user will only need to add a keyword to the jenkins_init.sh script. For example, for a Maven tutorial, the user can simply run ./jenkins_init.sh maven to start the tutorial.

Additionally, everything now works with Gitpod with just a click.

Things to do during the 2nd Coding Phase:

• Add more tutorials and integrate them with ./jenkins_init.sh.

• Provide support for Windows without WSL.

• Regularly test all the tutorial files and scripts.

• Develop concise and easy-to-understand documentation for new and updated tutorials.

End Note

A full recording from the meetup can be found HERE and slides are HERE.

https://www.jenkins.io/blog/2023/07/22/gsoc-2023-midterm/