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

The Jenkins Infra team was concerned about the dependencies used by third-party repositories. These repositories are a concern, not just for security reasons, but also for reliability.

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

This probe was requested by the community. In the ticket description, one of the plugin developers asked the Jenkins team to include a third-party repository in the plugin build. With the probe in place, the Jenkins team can now identify the plugins they should add to the build process.

In a Maven project, all the dependencies are listed in the pom.xml file. A plugin can have multiple pom files, and each module may have its own pom. This means that there can be multiple child poms in the same repository.

A major challenge in this probe was considering the parent and child pom relationship from all angles.

During code reviews and test cases, we noticed that there were assumptions made regarding Maven’s project hierarchies.

Furthermore, some edge-case scenarios were not considered while specifying the probe. Due to the number of open questions, this probe was put on hold until further research was completed. The goal of doing this was to adapt the project architecture to tackle the newly identified cases.

I implemented parameterized test cases to test the probe. Additionally, I extensively read the Maven documentation to understand how to test POM structure, inheritance, and Maven API.

This probe is currently partially completed, with approximately 60% of the code and test cases already implemented.

The objective is to create an efficient pom probe capable of aggregating all the parent-child pom relationships into a single file. By doing so, we can easily list the third-party repositories used in every pom file within the repository.

For more information or to find answers to any questions you might have, please visit the official GSoC 2023 project Adding Probes to "Plugin Health Score" description page.

The Jenkins Security team offers a GitHub action that automatically scans the plugin source code during Continuous Integration and reports security issues.

The Jenkins community considers using such tools to ensure a high-security level for plugins as a good practice.

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

This probe is essential from a security perspective, as it checks for known security breaches and vulnerabilities in a plugin.

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

This probe was originally started by another contributor. However, they were unable to continue, so I took over their work.

Additionally, this probe required refactoring existing classes to eliminate code duplication, as the JEP-229 (Continuous Delivery) probe also looks for CI configurations in GitHub Actions.

This probe will be beneficial to the security team, as it helps identify gaps and improve the security of the Jenkins plugin ecosystem.

During this project, I accomplished the following:

For more information or if you have any questions, please visit the official GSoC 2023 project Adding Probes to "Plugin Health Score" description page.

A bug fix, security fix, or new features are of no use unless they are released.

A production release not only provides users with an updated plugin, but also gives the developers a chance to get feedback on their work.

The "unreleased production changes" probe looks for unreleased commits in the production files.

If an unreleased file is found in the production path, the probe returns a failure message. If no unreleased file is found, it returns a success message.

This is my first probe that went live as a GSoC contributor.

The probe aims to identify unreleased production commits in Maven production files.

Finding an unreleased production file can mean one or more of the following:

Learning to use JGit, a Java library that implements a Git version control system, was one of the biggest challenges I faced when working on this probe.

Since I was not familiar with Git hierarchy, I struggled to find the parent of a child commit using JGit.

In the end, my mentors suggested a pair programming session to review the thinking process involved in implementing such a probe.

I am thankful for their kindness and patience.

When unreleased production files are found, the probe returns a failure status and the list of filenames.

When no unreleased production file is found, the probe returns a success message.

I hope there comes a day when test cases become my friends, but I don’t see this happening anytime soon.

Mentors suggested I should start with writing the test cases to reproduce the probe requirement(s), and later add code to pass each of the test cases.

This gave me an understanding of what the probe should actually do, and I learned to identify the test case scenarios.

Reading commits wasn’t possible without JGit Java library.

To implement JGit library and understand the features it provides, you should have strong understanding of Git concepts. I lacked depth in Git concepts that made me struggle with JGit.

This led me to strengthen the Git concepts along the way.

I once again realised the open-source world values quality.

The community is fine with fewer "quality" probes, as opposed to many "not-so-useful" probes.

Starting from ground zero is tough, whether implementing a new Java library or starting new work in another field.

However, with correct mentorship and guidance, you can rise up faster.

For more information or to find answers to any questions you might have, head to the official GSoC 2023 project Adding Probes to "Plugin Health Score" description page.

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.

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:

During Coding Phase 1, the following achievements were made:

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

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:

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:

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:

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.

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:

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

The Linux container images for Jenkins 2.419, 2.401.1, 2.401.2, and 2.401.3 have been rebuilt August 21, 2023.

Container images for Jenkins agents are not affected.

More details are available in the original issue report.

Plugins grow old and become difficult to maintain with time. GitLab Plugin was one such plugin that needed some love and care. The GitLab Plugin Modernization project thus aimed to modernize the GitLab Plugin by replacing the (RESTEasy) library with modern (GitLab4J-API) library via Jenkins (GitLab API plugin). The replacement normalizes the use of the GitLab API with regard to the (GitLab Authentication), (GitLab Branch Source), and (GitLab Logo) plugins. This modernization reduces future maintenance burden and improves the overall quality of the plugin by making it more lightweight due to reduced dependencies and enhanced documentation.

The migration was performed in the following 2 coding phases:

In this phase, the following tasks were completed:

The achievements of this phase were demonstrated in the Midterm Presentation.

In this phase, the following tasks were completed:

The results of this phase will be showcased in in the Final Presentation in the future.

My gratitude knows no bounds that I got the opportunity to contribute to such impactful project under Google Summer of Code with such kind mentors. I would like to thank my mentors, Kris Stern and Mark Waite for their constant support and guidance throughout the project. They put in a lot of effort in interactively testing the migrated plugin and providing me with valuable feedback. They never let me be stuck in any difficulty for too long and always helped me in finding the solution to the problem. I would also like to thank Basil Crow for the guidance he provided me with during the initial phase of the project, which helped the team shape the project.

Also, thanks to the org admins, Jean-Marc Meessen, Alyssa Tong, Kris Stern, and Bruno Verachten, for always keeping me and other contributors on our toes and assisting us with any blockers and concerns by organizing weekly stand-up calls and personal 1-to-1 meets every phase.