GSoC Building Jenkins.io with alternative tools

September 24, 2023, 10:43 pm

≫ Next: Supercharge Your Jenkins Workflow with Mergify

≪ Previous: Incremental Build Detection Probe

$

0

0

This blog showcases all the work done in the project Building Jenkins.io with Alternative Tools during Google Summer of Code 2023.

Table of Contents

1. About Project

2. Coding Phase 1

3. Coding Phase 2

4. Future Improvements

5. Acknowledgments

6. Useful Links

About Project

The Jenkins documentation site is generated as a static website using Awestruct from AsciiDoc sources. One of the drawbacks of the current build method is that the technical documentation is not versioned. It is thus not possible to view the documentation for a given Jenkins version. Only the latest can be viewed. This can lead to unnecessary confusion and is a worse experience than many other documentation sites like the git site, Python, and others. Another drawback of Awestruct is that for the last two years it has only been maintained by people from the Jenkins project. Relying on Awestruct is not a good thing in the long run.

The preferred set of tools that will replace Awestruct are Antora for its out of the box versioning functionality and Gatsby for it’s super fast builds.

The migration was performed in the following 2 coding phases:

Phase 1

In this phase, the following tasks were completed:

• I used Antora to migrate the user documentation which was versioned and the developer documentation which was non-versioned while keeping much of the functionality that we already have on jenkins.io.

• I migrated Tutorials, Guides, and Solution Pages which were all non-versioned.

• I fixed Interpage Linking across all the pages.

You can watch me talk about phase 1 of the project in the midterm presentation here.

Phase 2

In this phase, the following tasks were completed:

• I used Strapi CMS with Gatsby. I would also have liked to integrate Git Workflow here which was not suggested by mentors. Hence, It was not the perfect fit for Jenkins.

• I then moved to Gatsby and developed the blogs feature.

• I developed other pages like LTS Changelog, LTS Weekly, Download page and many more.

Here’s the link to the Final Presentation where you can watch me talk about the project’s final phase.

Future Improvements

• Some pages like changelogs and the Pipeline steps reference still need more refining and are missing some features that exist on the current documentation pages. I will continue working on the project to refine them and make it ready as a drop-in replacement for Jenkins.io.

Acknowledgments

I’m grateful that I got the opportunity to contribute to Jenkins under Google Summer of Code. I can say with confidence that Jenkins taught me a lot and I love learning so I don’t plan to stop contributing to Jenkins any soon. I was able to pull off the project to this extent only because of my mentors, Kris Stern, Mark Waite, Rajiv Ranjan Singh, and Yiming Gong. I am grateful for their constant support and guidance throughout the project. Their valuable feedback and insights into the project helped me a lot.

I would also like to thank the org admins, Jean-Marc Meessen for being a warm, father-like figure to me, Alyssa Tong for always making sure the meetings and the project demos go smoothly , Kris Stern for deep involvement in resolving development challenges. and Bruno Verachten for always checking up on me and all the other contributors.

Useful Links

• Github repo containing the code

• Use the Gitter channel or community.jenkins.io in case you have any question(s) or feedback.

---

Supercharge Your Jenkins Workflow with Mergify

September 26, 2023, 9:43 pm

≫ Next: Prototype removed from Jenkins 2.426

≪ Previous: GSoC Building Jenkins.io with alternative tools

$

0

0

Introduction

In the modern software development landscape, continuous integration (CI) and continuous deployment (CD) are no longer just trendy buzzwords. They are vital components of the development cycle. Two tools that are often associated with these operations are Jenkins and Mergify. Jenkins, an open-source automation server, is used to automate parts of the development process, including building, testing, and deploying applications. Mergify, on the other hand, is a powerful GitHub automation tool and merge queue that can simplify the management of pull requests.

Setting Things Up

Before we dive into the wonders of the Mergify-Jenkins tandem, let’s quickly walk through setting things up.

To get started with Jenkins, you need to install it on your server, and then you can use its rich set of plugins to define your build, test, and deployment pipelines.

Mergify, on the other hand, requires no installation. You integrate it with your GitHub account, and then you define your automation rules in a YAML file that lives in your repository.

The Power Duo: Jenkins and Mergify

Jenkins and Mergify are powerful tools individually, but when combined, they can take your DevOps workflows to the next level. The robust build and test automation provided by Jenkins are the perfect complement to Mergify’s ability to automate GitHub workflows, such as labeling, merging, backporting, and more.

By integrating Jenkins and Mergify, you’re essentially creating a powerful CI/CD pipeline. You’re able to automatically build, test, and deploy your software while also managing the various GitHub workflows in an efficient and streamlined manner.

Automating Pull Request Updates with Jenkins and Mergify

One particularly powerful combination of Jenkins and Mergify is in the area of pull request updates. Normally, if a Jenkins build fails due to a commit, someone has to notify the developer to update their pull request manually.

With Mergify, this process can be completely automated. Using Mergify’s pull request rules, you can configure a rule that will automatically request changes and comment on the pull request if the Jenkins build fails. This not only saves time but also ensures that issues are immediately flagged and addressed.

Step 1: Configure Jenkins Build Status Reporting

Firstly, you need to ensure that Jenkins is reporting the build status back to GitHub. This can be done using the GitHub plugin in Jenkins. After installing the plugin, go to the configuration of the job that you want to link with GitHub and find the "Post-build Actions" section. There, add "Set GitHub commit status (universal)" and configure it to update the status of the commit in GitHub based on the build result.

Step 2: Set Up Mergify Rules

Next, in your GitHub repository, you need to create a .mergify.yml file where you’ll define your automation rules. Here’s an example of a rule that comments on and labels a pull request if the Jenkins build fails:

pull_request_rules:-name:comment on PR if build failsconditions:# Replace with the actual name of your Jenkins reported check-check-failure=Jenkinsactions:comment:message:"TheJenkinsbuildhasfailed.Pleasereviewyourchanges."label:toggle:-build-failed

In this configuration:

• The conditions section checks if the Jenkins build is unsuccessful.

• The actions section defines what actions Mergify should take if the conditions are met. In this case, it will add a comment to the pull request and apply the label build-failed.

If you wanted to also update the pull request with the latest change from its base branch to see if that’d make it work, you could use the update action from Mergify also:

pull_request_rules:-name:comment and update on PR if build failsconditions:# Replace with the actual name of your Jenkins reported check-check-failure=Jenkinsactions:comment:message:"TheJenkinsbuildhasfailed.Pleasereviewyourchanges."label:toggle:-build-failed# Merge PR base branch into the PR, this will retrigger the CIupdate:

Step 3: Commit and Push .mergify.yml File

Lastly, commit this file to your repository, and Mergify will start automating based on the rules you’ve defined.

Ensuring Secure Mergify Merges with the Merge Queue

Another powerful way you can combine Jenkins and Mergify is by using the Merge Queue feature. The merge queue is a strategy offered by Mergify to secure your repository’s main branch state. It ensures that the main branch is always green by validating that each pull request integrates correctly before merging.

With Jenkins as your continuous integration (CI) system, you can ensure each pull request is thoroughly checked before it gets added to the merge queue. Here’s how you can configure this:

Step 1: Set Up Jenkins for CI

As the first step, ensure your Jenkins setup is correctly reporting the build status to GitHub, as explained previously. Each pull request should trigger a Jenkins job, which subsequently updates the pull request status based on the build result.

Step 2: Configure Mergify Merge Queue

Next, in your .mergify.yml file, you can set up a rule that places the pull request in a merge queue once it’s approved and all CI checks, including Jenkins, pass. Below is an example configuration:

queue_rules:-name:defaultmerge_conditions:-"#approved-reviews-by>=1"-check-success=Jenkinsrouting_conditions:-"#approved-reviews-by>=1"-check-success=Jenkins

In this configuration:

• The queue_rules section sets up a merge queue named default.

• A pull request is added to this queue when it has at least one approval (#approved-reviews-by>=1) and the Jenkins check is successful (check-success=Jenkins) — this is what the routing_conditions are for.

• The pull request is merged once it’s updated and still has Jenkins checks passing, plus the required approval.

Step 3: Commit and Push .mergify.yml File

Once you have updated the .mergify.yml file with the above rules, commit and push the file to your repository.

With this setup, each pull request must pass the Jenkins build and get approval before Mergify adds it to the merge queue. Only when the pull request at the front of the queue passes all checks, it gets merged, ensuring the main branch’s integrity.

By coupling Jenkins' robust CI functionality with Mergify’s merge queue, you can make your development workflow much more efficient and error-proof, saving your team time and reducing the risk of breaking your main branch.

Conclusion: Harness the Power of Jenkins and Mergify

With Jenkins handling the building, testing, and deploying of your software and Mergify managing your GitHub workflows, you have a truly powerful and streamlined CI/CD pipeline. This combination allows you to automate your workflows, improve efficiency, and ultimately deliver better software.

By embracing tools like Jenkins and Mergify, you’re not just keeping up with modern DevOps practices; you’re also investing in the long-term productivity and success of your software development projects.

So, are you ready to supercharge your Jenkins workflow with Mergify? Try for free

Prototype removed from Jenkins 2.426

October 9, 2023, 9:13 pm

≫ Next: Jenkins September 2023 Newsletter

≪ Previous: Supercharge Your Jenkins Workflow with Mergify

$

0

0

Following up on my previous post about removing Prototype from Jenkins, Prototype has been removed from the 2.426 weekly release and will be removed from the November LTS release. This removal required changes in about 60 plugins. Use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.426.

A migration of this scope would not have been possible without the support of the entire Jenkins community. In particular, we would like to thank Tim Jacomb and Rahul Somasunderam for doing a large portion of the development work. Additionally, we would like to thank the following contributors for participating in the removal of Prototype from the Jenkins project by developing, reviewing, or releasing a Prototype-related change in the jenkinsci and/or jenkins-infra GitHub organizations:

• Adrien Lecharpentier

• Alexander Brandes

• Alexis Tual

• Allan

• Bhagyashri Sapnar

• Bruno Kinoshita

• Bruno Verachten

• Carroll Chiou

• Christopher Orr

• Dan Alvizu

• Daniel Beck

• Devin Nusbaum

• Dmitry Platonov

• Fred G

• Gavin McDonald

• Go Sueyoshi

• Ioannis Moutsatsos

• Iurii Ignatko

• James Nord

• Jan Faracik

• Jesse Glick

• Jiri Vanek

• Joe Hansche

• Jose Blas Camacho Taboada

• Josh Aguilar

• Kanstantsin Shautsou

• Kevin Martens

• Kris Stern

• Markus Winter

• Mark Waite

• Martin Pokorny

• Michael Tughan

• Oliver Gondža

• Olivier Lamy

• Pierre Beitz

• Raihaan Shouhell

• Robert Sandell

• Roland Asmann

• Timka Dyussyumbayev

• Tobias Gruetzmacher

• Ullrich Hafner

• Victor Balakine

• Wadeck Follonier

• Yaroslav Afenkin

• Zbynek Konecny

Thank you for your contributions, and I hope to see many of you again in the javax to jakarta API migration.

Jenkins September 2023 Newsletter

October 12, 2023, 9:13 pm

≫ Next: What is the plugin health score?

≪ Previous: Prototype removed from Jenkins 2.426

$

0

0

Key Takeaways

• JDK21 is around the corner

Contributed by: Wadeck Follonier

• A plugin security advisory was published on September 6.

  • Security Advisory 2023-09-06

  • This included multiple high score vulnerabilities in various plugins.

• A core security advisory was published on September 20.

  • Security Advisory 2023-09-20

  • Multiple vulnerabilities were corrected in core.

  • This advisory also included fixes for a plugin.

Contributed by: Mark Waite

Voter registration is now open for the 2023 Jenkins elections. We’re electing two board members and all five officers. Jenkins contributors must register to vote in each year’s elections.

How do I register to vote?

More detailed instructions are available in the Jenkins elections 2023 blog post.

New Jenkins features

The 10 year old JavaScript library, Prototype.js, has been removed from Jenkins 2.426 as announced in a recent blog post by Basil Crow. The Jenkins board extends its sincere thanks to Tim Jacomb, Basil Crow, Rahul Somasunderam, and many others that worked to remove that old library from Jenkins core and over 60 plugins.

Contributed by: Damien Duportal

• The bandwidth reduction on Artifactory is complete as repo.jenkins-cio.org no longer mirrors Apache Maven repositories, thanks to our infrastructure caching. We’ve seen a decrease of more than 50% in monthly outbound downloads.

• We’ve been doing some plumbing work to increase the availability of jenkins.io web services during operations (or those pesky unplanned infrastructure problems). No more outages when upgrading Kubernetes for replicated services. That’s right, we’ve got your back!

• We have a new sponsor for the Jenkins Project in Cloudflare. We’re currently evaluating migrating updates.jenkins.io to their system next month. Exciting times ahead!

• ARM64: We’ve migrated 5 new services, making for a total of 7, from x86 to ARM64, including jenkins.io and javadoc.jenkins.io. We’re moving on up!

• It’s time to say goodbye to Oracle Cloud! The sponsorship has ended and archives.jenkins.io now runs on DigitalOcean. We’re grateful to both of these providers for their past and present help. Here’s to new beginnings!

Contributed by: Bruno Verachten

• JDK21

  • Infrastructure

    • We’re working with updatecli to keep the JDK21 updated.

    • We’re still waiting for the official release.

  • Docker images:

    • Ssh agent: first JDK 21 preview images

    • Docker agent: first JDK 21 preview images

    • Inbound agent: first JDK21 preview images

    • Controller: first JDK21 preview images

• Java 11, 17, and 21 with Jenkins

  • Refer to Mark Waite’s Google Doc for further information.

    • A draft was sent to the Jenkins board and officers.

  • Since a pciture is worth a thousand words, here is a diagram.

  • It needs further discussion and refinement before it is finalized.

• Work on agent and controller images

  • Docker-agent received a few version bumps and two breaking changes, resulting in seven releases.

    • 💥 Breaking change: Moving to bookworm.

    • 💥 Breaking change: Using a ltsc2019 base image for windowsservercore-ltsc2019 agent images.

  • Inbound-agent received a few version bumps and two breaking changes, resulting in four new releases.

    • 💥Breaking change: Moving to bookworm.

    • 💥Breaking change: Using a ltsc2019 base image for windowsservercore-ltsc2019 agent images and add a nanoserver-ltsc2019 image.

Contributed by: Kevin Martens

During September, there were several updates for the community blog and Jenkins documentation.

First, there were 10 blog posts written by 11 different authors. The blog posts include updates and recaps for the Google Summer of Code, the 2023 Jenkins board and officer elections, and a review of the Artifactory bandwidth reduction project.

The Jenkins security section now includes a list of all security issues since 2018. This list compiles all security issues that have been published in a security advisory.

Finally, a new Platform Information section was added to the Jenkins user handbook. This section contains support polciies for the Jenkins platform and upgrade guides for Java versions in Jenkins.

Contributed by: Alyssa Tong

Hacktoberfest is in progress!

There’s still time to register, pick your projects, and contribute. Registration is between September 26 and October 31 on the Hacktoberfest site. Read how you could contribute to Jenkins.

Jenkins in Google Summer of Code 2023 has concluded!

Congratulations to all 4 GSoC contributors for their completion of this year’s program. Read more about their projects in their blog posts below:

• GSoC Building Jenkins.io with alternative tools

• Incremental Build Detection Probe

• Renovate Probe

• Detecting deprecated JSR-305 imports Probe

• Number of open issues Probe

• Docker-based Jenkins quick start

• GitLab Plugin Modernization

What is the plugin health score?

October 26, 2023, 1:43 am

≫ Next: Back of the Napkin Guide to Updating Jenkins, for the uninitiated

≪ Previous: Jenkins September 2023 Newsletter

$

0

0

Short story long

As of October 24th, there is a new tab named Health Score on each plugin page of plugins.jenkins.io.

This new tab provides the plugin’s health score, along with every aspect that contributed to its score. The score is meant to be unbiased and all plugins are evaluated the same way.

Here is what it looks like:

.

Back to the beginning

This project started during the Google Summer of Code 2022 and was finished during the Google Summer of Code 2023. We created the Plugin Health Scoring project with and for the Jenkins community.

The purpose of the project is to provide an unbiased score to all plugins. The resulting score is based on data retrieved from each plugin, and this data is analyzed the same way for every plugin.

Understanding the scores

The scores are based on several data points gathered from each plugin. We use the update-center.json to populate the list of plugins and their source code location.

Based on that, we run what we call probes on each plugin. The purpose of these probes is strictly to gather data such as:

• Is there a Jenkinsfile within the plugin repository?

• When was the last commit on the default branch of the repository?

• etc.

Here is the list of probes used in the project, and you can find their source code in their repository.

Once the data is gathered, we run a list of scoring processes, which grade all plugins based only on the available data. All plugins are then scored using the same criteria. You can find the list of scoring processes on the Plugin Health Score site and their implementation in the Plugin Health Score repository.

Refer to the Plugin Health Scoring project documentation for further information about the architecture and behavior of the project.

How is it displayed?

The score of every plugin is fetched when the plugin site is built. That data is then used to build the /<plugin-name>/healthscore/ page, using the component PluginHealthScore. That component can be found in the plugin site repository.

The scores and different categories are dynamic, and are coming directly from the Plugin Health Scoring project.

Disclaimer

The scores are not perfect and are just another indicator of the plugin state. We are still working on using more data from the plugin to contribute to the score.

The grading system that generates the score for each plugin is, I believe, subjective. However, it is not written in stone and can, and most likely will, evolve in the future.

If you feel there is something incorrect about a plugin score, this may indicate a false negative. Please raise an issue on the Plugin Health Scoring project if the score does not appear to be accurate.

Links

• Plugin Health Scoring

• Google Summer of Code 2022 project page

• Google Summer of Code 2023 project page

Back of the Napkin Guide to Updating Jenkins, for the uninitiated

November 1, 2023, 3:43 am

≫ Next: Introducing the 2 + 2 + 2 Java support plan

≪ Previous: What is the plugin health score?

$

0

0

.

Prologue

Here’s a brief account of my journey to update my Jenkins Servers. Think of this as a "back of the napkin" guide that I used to research and upgrade my Jenkins Servers, which had been left unattended for far too long. I know many of you are seasoned experts - I wasn’t. I’ve included references that I found useful in my research, but keep in mind, your setup may be different from mine. I hope this helps others in their journey.

Yours in Jenkins, Marc

“This is the way”

Pre-work:

Grab your plugin list and dive into the Change log. You’re going to want to pore over EVERY change log from your current version to your target version, and every single iteration in between. Keep an eye out for any mentions of your plugins and Java versions (both client and primary) in the Change Log. You’re building a validation checklist here (e.g., does SSH still work? Is the plugin functioning properly?).

ADDED ROI: While you’re scrutinizing your plugins, take a moment to consider which ones are gathering dust. Are any of them deprecated? Do you still need them? Try deactivating them (before you outright remove them) and see if anyone kicks up a fuss.

Backup Security roles and Users: If you’re using LDAP/AD, make offline copies of your Security groups and access, User Lists and Security groups (<jenkins_url>/manage/role-strategy/&& <jenkins_url>/manage/role-strategy/assign-roles). Don’t forget to backup configurations to access the Active Directory too (<jenkins_url>/configureSecurity/).

Let the work begin:

1. Get cozy with your backups for those inevitable rollbacks. I had quite the love affair with plugins…​ making a tar/zip archive of /JENKINS_HOME/plugins was a lifesaver. Some plugins, like Active Directory, really threw me for a loop during updates.

2. SNAPSHOTS: Take them at the beginning, and after each benchmark, if you can afford the luxury.

3. Update Plugins: Aim for the highest compatible level. I found that reaching for the "highest level" sometimes led to unnecessary headaches. Keep it simple, kid. SNAPSHOT: Archive the <JENKINS_HOME>/plugins/ folder.

4. Update the Core application: Stick with the method you used for the initial install. I’m running on RHEL and used yum…​ I tried getting fancy with downloading the war file, but it kept throwing tantrums…​ Stick with what you know. Keep in mind, versions pre-2.400 used a different security key than post-2.400 (Jenkins 2.397 and 2.387.2: New Linux Repository Signing Keys).

5. Update plugins AGAIN: Aim for the highest "compatible" level (hopefully, it’s the highest level now).

6. Plugin configuration: My CVS plugin was a bit needy, requiring files not in the hpi install file. Follow the appropriate plugin documentation to satisfy these dependencies. Establish connections to external databases and services (AD/CVS/etc.). Special anecdote: I had a bit of a tiff with the "Require TLS" checkbox for the LDAPS connect…​ a conflict needed to be resolved. Specifically, I had to tweak the systemctl for Jenkins…​ ensure -Dhudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true was removed before enabling that checkbox, else you’ll be dealing with authentication errors with LDAPS _Reference

7. Validation: Time to check that list you made earlier…​ can you SSH out to client servers? Can you connect to your external services/databases?

Cleanup:

Depending on the scale of your upgrade, you might want to re-examine your plugins. Some plugins might have been sent out to pasture as their functionality gets folded into the Core. Consider these plugins for deactivation, and maybe even removal down the line. This little cleanup could help plug some security holes (and put a smile on your CISO’s face). Remember to do a little jig after each disable/remove and application recycle.

Epilogue

This is a story without an end…​ It’s not a one-and-done deal. After I finished the upgrade cycle, I made weekly pilgrimages to each server to update plugins, disable ones that seemed to be gathering dust, remove the ones that WERE just collecting dust, and address any warnings that popped up in the Jenkins UI. The more you do it, the easier it gets. I had a few practice runs on my sandbox server before I dared to touch the production servers. And I kept taking snapshots as I went along, like a tourist in my own code.

This is my tale…​ now it’s time for you to write yours.

References:

• Core app updated

  • Installation guide for Jenkins

  • Installation guide for Jenkins RHEL

• Change log

  • Jenkins Change Log for upgrades

• Plug-in references

  • Jenkins Plugin Library

  • Jenkins Active Directory Plugin

    • Active Directory forceLdaps guidance

  • Jenkins Dimensions Plugin

  • Jenkins Role Strategy

• Supplementary reading

  • Upgrading Jenkins with a WAR file My initial drafts were based on this process

  • How to Upgrade Jenkins on Windows/Linux Server I used this for Troubleshooting guides tips and tricks

Introducing the 2 + 2 + 2 Java support plan

November 8, 2023, 6:45 am

≫ Next: Jenkins October 2023 Newsletter

≪ Previous: Back of the Napkin Guide to Updating Jenkins, for the uninitiated

$

0

0

Summary

tl;dr Jenkins 2.426.1 LTS will support Java 11, 17, and 21. In Fall 2024, Jenkins will require Java 17 or 21 and drop support for Java 11. Thereafter, Jenkins will support each Java LTS release for approximately four years; i.e., Jenkins will support two Java LTS releases at any given time.

Background

Java’s historically slow release cadence has accelerated significantly in recent years. At present, Java feature releases are delivered every six months, with a long term support (LTS) release every two years that is supported for about six years. Java feature releases are conceptually analogous to Jenkins weekly releases in that they allow developers to release early and often, while Java LTS releases are conceptually analogous to Jenkins LTS releases in that they benefit large scale users. The similarity between Java releases and Jenkins releases ends at the conceptual level, though — in practice, each project has a vastly different schedule regarding how often each type of release is performed and how long each type of release is supported.

Two categories of users

The above illustrates the needs of two categories of users: developers and early adopters, who benefit from releasing early and often; and large scale users, for whom predictability and stability are the primary consideration. The latter will tend to prefer both Jenkins and Java LTS release lines and delay upgrading until after the early adoption phase has passed or until it is absolutely necessary to upgrade. The changes to Java’s release schedule in recent years raise the question of how to align Java adoption within the Jenkins project with Java’s own release cadence, which has accelerated significantly in recent years.

Rejected proposal: Support three Java LTS releases at any given time

Eclipse Temurin and Red Hat both support their Java LTS releases with security patches for about six years, and in practice Java vendors will continue to maintain a Java LTS release for as long as there is market demand for it. One answer to the question raised above, then, would be for the Jenkins project to support each Java LTS release for six years, matching the support offered by upstream Java vendors like Eclipse Temurin and Red Hat. This strategy primarily benefits large scale users for whom stability is the primary consideration, but for various reasons that we will explore below it fails to meet the needs of developers and early adopters.

Rejected proposal: Support one Java LTS release at any given time

At the other end of the spectrum, the Jenkins project could support each Java LTS release for only as long as it takes for the next Java LTS release to be delivered; i.e., for two years rather than six. This strategy would benefit developers and early adopters, and these benefits go beyond the mere availability of shiny new language features for developers — newer Java runtimes have implemented a significant number of performance optimizations that are of interest to operators, and an increasing number of third-party library dependencies require the adoption of a recent Java LTS release in order to receive bug fixes and security patches.

Additionally, the Jenkins ecosystem consists of thousands of loosely-connected components, and building and testing them across all supported Java versions is a nontrivial effort, notwithstanding recent advances in dependency updating. Reducing the build and test matrix to a single version would save hundreds of thousands of dollars in cloud costs, to say nothing of the savings in development costs that are associated with the decreased cognitive load of a simpler build and test matrix. However, this strategy fails to meet the needs of large scale users, who want to adopt a Java LTS release and stick with it for as long as possible before upgrading to the next Java LTS release.

Accepted proposal: 2 + 2 + 2 Java support plan

The above discussion highlights two categories of users, each of whose needs are legitimate but, through no fault of their own, are in conflict with each other. The natural solution, then, is to compromise at the midpoint. Therefore, the Jenkins project is adopting a 2 + 2 + 2 Java support plan, where Jenkins supports a new Java LTS release in the first two years after the general availability of that Java LTS release, then requires that Java LTS release as the Jenkins minimum Java version in the next two years of that Java LTS release’s upstream support, then drops support for that Java LTS release two years before that Java LTS release reaches end of life upstream.

In practice, this means that Jenkins will support a given Java LTS release for approximately two-thirds the amount of time that upstream Java vendors do, that Jenkins will support two Java LTS releases at any given time rather than three, and that large scale users can stay on a Java LTS release for four years at a time. This plan balances the needs of large scale users for predictability and stability with the needs of early adopters and developers to improve and simplify Jenkins with the latest Java capabilities and to reduce the maintenance overhead associated with a large build and test matrix.

Upcoming dates

2023-11-15

Jenkins 2.426.1 LTS will support Java 11, 17, and 21.

2024-11-15

Jenkins LTS will require Java 17 or 21 and drop support for Java 11.

Thereafter, the 2 + 2 + 2 support plan will take effect as described above. Check this blog for detailed dates at that time.

Conclusion

As the age-old adage says, a good compromise is when both parties are equally dissatisfied, and we recognize that this plan is not ideal for either category of user. However, we feel that it optimizes globally for the sustained progress of the Jenkins community as a whole, ensuring that the software and the community around it remain relevant for a wide variety of people and use cases. As the Jenkins project nears its 19th birthday, we look forward to the establishment of a sustainable software development lifecycle that can serve the project’s valued users and contributors for years to come.

Jenkins October 2023 Newsletter

November 10, 2023, 10:13 am

≫ Next: Jenkins Contributor Summit in Brussels

≪ Previous: Introducing the 2 + 2 + 2 Java support plan

$

0

0

Key Takeaways

• JDK21 is available on the infrastructure and in official Docker images too.

• 💥Breaking change: set Java 17 as default for LTS.

• Prototype has been removed as of weekly 2.426

Contributed by: Wadeck Follonier

• Core security advisory published on October 18

  • https://jenkins.io/security/advisory/2023-10-18/

  • Includes an essential Jetty update that provided multiple fixes.

• Plugin security advisory published on October 25

  • https://jenkins.io/security/advisory/2023-10-25/

  • Multiple high score vulnerabilities in various plugins

• During Hacktoberfest, the Content Security Policy topic got some attention with several PRs being proposed.

  • For more information, refer to the related ticket.

Contributed by: Mark Waite

The 2 + 2 + 2 Java support plan has been announced as the Jenkins project approach to support Java versions now and in the future. We plan to generally support two Java LTS releases at any one time, with a transition period over the next 2 years.

Java 21 support by the Jenkins project is looking very, very good. Jenkins 2.426.1 is scheduled to be released Nov 15, 2023 with full support for Java 21. Read more about the Java support plan in the recent blog post from Basil Crow. Thanks to Basil Crow, Bruno Verachten, Alexander Brandes, Mark Waite, and many others for their efforts to bring Java 21 support to Jenkins users.

Jenkins 2.426.1 will also be the first LTS release that removes Prototype.js. Jenkins 2.426 weekly removed Prototype.js after 6 months of work across over 50 plugins. Sincere thanks to Tim Jacomb, Basil Crow, and many others for finishing the project that was first announced in May 2023.

57 Jenkins contributors are registered to vote in the Jenkins elections. Thanks for your involvement in Jenkins and for your interest in assuring that the project has the leadership it needs.

Contributed by: Damien Duportal

• Stabilization of the plugins.jenkins.io website (JDK upgrade to avoid OOM kills due to cgroupsv2, decrease resource usage)

• General availability on ci.jenkins.io of:

  • JDK21 21.0.1 (GA) - except for s390x

  • Maven 3.9.5

  • JDK8, 11 and 17 quarterly updates

• Jenkins & plugins:

  • Jenkins LTS 2.414.3 (less than 6 hours after publication)

  • Plugin advisory (less than 2 hours after publication)

• Costs and safety:

  • All of our Terraform states were migrated from AWS to Azure.

  • Kept our Azure bill at $7.5k

• JDK19 removed from the platform

• ARM64 migration:

  • 5 new services migrated (total of 12)

  • Ingress (nginx), datadog and cert-manager migrated

Contributed by: Mark Waite

The Jenkins user experience continues to improve thanks to the efforts of contributors from many different areas. Special thanks are due this month to Tim Jacomb (Prototype.js removed from Jenkins core), Mustafa Ulu (consistency improvement and Turkish localization), Daniel Beck (form validation fixes and boolean build parameter display fixes), Markus Winter (nested page elements fixes), Julien Greffe (French localization improvements), and Vincent Latombe (allow cloud reordering).

Notes and video from the monthly user experience SIG meeting are available for review.

Contributed by: Bruno Verachten

• Latest Java releases - progress with installation and Jenkins development

  • Oct 18, 2023 Oracle patch day

    • Java 11.0.21

    • Java 17.0.9

    • Java 21.0.1

• Java 21 support

  • Jenkins enhancement proposal by Mark Waite is progressing nicely

  • Progress testing the top plugins with Java 21

    • 36 are now tested with Java 21 (Jenkinsfile modified)

    • 90 are known to work with Java 21

    • 13 don’t work yet with Java 21 (too outdated, using gradle, not in jenkinsci organization)

  • In infra, finished the transition to official JDK 21.0+35.

  • All agents and controllers now supply a JDK21 or JDK21 preview Docker image.

• Java 17 is now the default Java version used in the Docker images, even for the LTS:

  • If you don’t use a tag specifying the JDK version like 2.429-jdk11 but shorter tags like 2.429, you will end up with an image using JDK17 and not JDK11 anymore.

Contributed by: Kevin Martens

There were only three blog posts during October, including the September newsletter. However, the two non-newsletter posts provide great information. The Plugin Health Scoring blog post, from Adrien Lecharpentier, announces and shares insight into the plugin health scoring system, and what that score means for a plugin. The guide to update Jenkins, from new author Marc Phillips, provides instructions on how to update Jenkins and what his process looks like.

Additionally, we received several documentation updates from new Jenkins contributors. While these may not have been huge changes, the effort and work done by new community members is always appreciated. Thanks to everyone who contributed during October and Hacktoberfest!

Contributed by: Alyssa Tong

Hacktoberfest has reached a successful end. More than 60 additional people have contributed to Jenkins during the month of October than in the previous month. Thanks to DigitalOcean for their sponsorship of open source through Hacktoberfest.

---

Jenkins Contributor Summit in Brussels

November 11, 2023, 7:13 pm

≫ Next: Introducing the Jenkins Contributor Spotlight

≪ Previous: Jenkins October 2023 Newsletter

$

0

0

We are happy to announce that we will hold a Jenkins Contributor Summit in Brussels prior to FOSDEM.

FOSDEM is a free event for software developers to meet, share ideas, and collaborate. Every year, thousands of developers of free and open-source software from all over the world gather at the event in Brussels. For the 2024 event, FOSDEM will occur between February 3 - 4, the first weekend of February.

What is a Jenkins Contributor Summit?

The Jenkins Contributor Summit brings together current and future contributors to the Jenkins project. At this event, we will talk about the current state of the project and its future evolution. It is a great opportunity to meet fellow members of the Jenkins community "in real life".

It is a day-long event (from 10h00 to 17h00) featuring presentations on the "State of Jenkins", Project/SIG updates, discussion on various key projects, "Ignite Talks", and demos.

Don’t hesitate to reach out if you want to submit a presentation, talk, or demo! Refer to the Contact section to find out how to get in touch.

Key Dates:

• Jenkins Contributor Summit: Friday 2 February 2024

• FOSDEM: Saturday 3 and Sunday 4 February 2024

Location:

• Betacowork, located at 4 Rue des Pères Blancs, 1040 Brussels, Belgium The Betacowork location is easily accessible from downtown Brussels or the FOSDEM venue.

Entry Fee:

• No cost to attend.

• Registration will be required (room capacity: 30).

• Event is in-person only.

• No catering is foreseen but food can be purchased in the neighborhood.

Contact

• SIG - Advocacy & Outreach

• Contact: Alyssa Tong, Bruno Verachten, Jean-Marc Meessen

• Community: via Community Forum (to be created)

---

Agenda (Draft)

• Board report - (Jenkins Governance Board member)

• Infrastructure officer report - Damien Duportal

  • Funding, sponsorships, and cost savings

  • Modernization

• Docs officer report - Kevin Marten

• Release officer report - Tim Jacomb

• Events officer report - Alyssa Tong

• Security officer report - Wadeck Follonier

• User Experience SIG report - Tim Jacomb or Mark Waite

  • Progress, next steps, etc.

• Platform SIG report

• Java support plan

• Hardware support

• Initiatives and roadmap

Introducing the Jenkins Contributor Spotlight

November 29, 2023, 10:45 pm

≫ Next: [Google Summer of Code 2024] A Call for Mentors

≪ Previous: Jenkins Contributor Summit in Brussels

$

0

0

The Jenkins project has evolved constantly over the years, thanks to the tireless efforts of the Jenkins community. There are numerous contributors that work behind the scenes to ensure that Jenkins is functioning and staying on the cutting edge, in addition to being voices within the community and advocating for Jenkins. It is with this sentiment in mind that we want to acknowledge and share our appreciation for these contributors. Therefore, we are excited to announce and introduce the Jenkins Contributor Spotlight page, with our first contributor spotlight for Alexander Brandes!

This is the result of several months of research, collaboration, and determining who some of the heaviest Jenkins contributors are. Thanks to Alyssa Tong, Jean-Marc Meessen, and Bruno Verachten for organizing the project, retrieving the data that was used, and guiding the project direction. We also want to share thanks to Cristina Pizzagalli for helping us design the site and Kris Stern for all of their work creating the site and working with the Infrastructure team to get the site integrated. To get started, we reached out to the top ~30 contributors to better understand their backgrounds and gather some insight into their Jenkins experiences. Thankfully, everyone that has responded has shared not only their Jenkins background and experience, but also some of their personal background. This is a wonderful representation of the global reach that the Jenkins community has, and we want to ensure that there is a human element in addition to the technical parts.

Ultimately, Jenkins would not be where it is without the efforts of the greater community. We want to share our deepest thanks and appreciation to all Jenkins contributors, and highlight some of the heaviest lifters.

[Google Summer of Code 2024] A Call for Mentors

December 7, 2023, 10:46 pm

≫ Next: Log from Jenkins Jobs to GitHub Pull Requests as Checks

≪ Previous: Introducing the Jenkins Contributor Spotlight

$

0

0

We are happy to announce that Jenkins is preparing to participate in its eighth (8th) year in Google Summer of Code (GSoC).

What is Google Summer of Code?

Google Summer of Code (GSoC) is a global, online mentoring program focused on introducing new contributors to open-source software development. GSoC contributors work on a 10-22 weeks-long programming project with the guidance of mentors from their respective open source organizations. During GSoC, accepted contributors are paired with mentors from participating open-source organizations of their choice, gaining exposure to real-world software development techniques. These GSoC contributors will get to learn from experienced open-source developers while writing code for real-world projects! A small stipend is provided as an incentive to support their open-source contributions. Refer to the GSoC contributor eligibility documentation for more details.

Why might you consider being a Jenkins in GSoC mentor?

Mentor interaction is a vital part of GSoC. Mentoring is a great opportunity to improve your management and people (or general “soft”) skills while giving back to the community. In return for mentoring, a GSoC contributor works on your project full-time for 10-22 weeks. Think about the projects that you’ve always wanted to do but never had the time to complete. GSoC is a fantastic program and the Jenkins project is looking forward to participating in it again in 2024, potentially with your participation!

What does mentoring involve?

Potential mentors are invited to read the information for mentors. Note that being a GSoC mentor does not require expert knowledge of Jenkins. Mentors do not work alone. We make sure that every project has at least two mentors. GSoC org admins will be there to help to find technical advisers, so you can study together with your GSoC contributor. Mentoring takes about 5 to 8 hours of work per week (more at the start, less at the end). Mentors provide guidance, coaching, and sometimes a bit of cheerleading. They review GSoC contributor proposals, pull-requests, and contributor presentations at the evaluation phase. They fill in the Google-provided final evaluations at the end of the coding period.

So you want to be a mentor but don’t have a project idea? We can help with that!

GSoC project ideas are coding projects that potential GSoC contributors are expected to accomplish in about 10-22 weeks. The coding projects can be new features, plugins, test frameworks, infrastructure, graphical interface, etc. If you don’t have a specific project idea, please consider being a mentor for one of these project ideas. If you have a specific project in mind, please send us your project ideas before the beginning of February, so they can get a proper review by the GSoC committee and by the community. Of course, we would love it if you were the mentor for your project idea.

How to submit a project idea

Create a pull request with your idea in a .adoc file in the project ideas. It is not necessary to submit a Google Doc, but it will still work if you want to do that. Refer to the instructions on submitting ideas which include an .adoc template and some examples.

Need more inspiration?

Case in point, the Plugin Health Score. A GSoC project idea that started in the summer of 2022, and was implemented in the summer of 2023 for millions of Jenkins users to benefit from!

We look forward to welcoming new mentors for GSoC 2024!

For any questions, you can find the GSoC Org Admins, mentors and participants on the GSoC SIG Gitter chat.

Log from Jenkins Jobs to GitHub Pull Requests as Checks

December 7, 2023, 10:46 pm

≫ Next: Welcome Basil Crow - new Jenkins Governance Board member

≪ Previous: [Google Summer of Code 2024] A Call for Mentors

$

0

0

You have a GitHub repo and a Jenkins server. The Jenkins server has jobs for running unit tests, computing code coverages, and executing static analyses.

Every time someone opens a PR to your repo, you ask them to run those jobs, take screenshots of the results, and paste these screenshots to the PR description as a proof of quality.

That’s too much waiting and too many keystrokes. People want automation: when they create a PR (or push a commit), those jobs should start to build. When the builds are done, the results should be conveniently visible at the "Checks" section at the bottom of the PR, like this:

Ways to publish checks to PRs: Statuses, Checks, and Actions

You thought about your options. There are 3 types of entries that can be shown in this little box. In order of increasing complexity to configure:

1. Statuses, or as I’d like to call them, Commit Checks. They are associated with commits, not PRs. This means you can run them even without creating a PR. For example, here are some Commit Checks on a commit I directly pushed to a master branch:

2. Checks, or more explicitly, PR Checks. These are run on commits but are stored with the PRs. With them, you can write long essays of messages to the "Checks" tab of a PR, but they do require authenticating as a GitHub App instead of a user, so it’s more complicated to set up. SonarCloud, a code analyzer, makes use of PR Checks via their namesake GitHub App. If you look closer, their report is just Markdown:

3. GitHub Actions (GA). GA is a different kind of CI system from Jenkins. Since this article is about Jenkins only, GA is only mentioned here for the sake of completeness.

When the result is simple: Use commit statuses

The Jenkins jobs you want to trigger only run for a couple of seconds. Each only emits a simple result: pass or fail. You don’t need fancy reports, so commit statuses seem to be a suitable choice.

You installed the GitHub plugin to your Jenkins server and followed this guide to set it up. You are now able to emit simple one-liners as checks like this:

(source of screenshot; Apache 2.0 licensed)

It met your immediate need, but it stills falls short in a number of ways:

• The plugin publishes to the PR only thrice: upon getting queued, upon the start, and upon completion. Your job actually has many time-consuming stages, such as building a manifest, deploying to staging, and running tests. These stages are often packed in a single script and you want to be notified at each stage.

• The messages show up with your GitHub profile image as the icon, because Jenkins is using your PAT! You want to shy away from the spotlight, maybe because you don’t want to be mistaken by your less-GitHub-savvy collaborators as a ruthless robot critiquing (and blocking) everybody’s PRs.

That’s when you start to look further.

When the report is long: Use PR checks

Your job generates a long report at the end, but the Checks section can only accommodate a couple of words. You have been rendering the reports as HTML and attaching them to the Jenkins builds themselves (perhaps with a nice Jinja2 template and the HTML Publisher plugin). The commit statuses your job writes to PRs contain links to the Jenkins builds themselves, so it’s only two clicks away from an HTML report — not bad.

To prevent past HTML reports from saturating the disk, you configured the job to only keep the 20 most recent builds. Then the team grew and people started complaining that their reports are getting purged before they could even take a look. You now have a scalability problem.

Let’s move those reports away from Jenkins, and what’s a better place than the PRs themselves?

Following this guide from CloudBees, you created a GitHub App, installed it onto your repo, generated a SSH private key for the app, and uploaded it to Jenkins credentials storage with "GitHub App" as the Kind. (For the GitHub half of the journey, this tutorial has better screenshots.) Now that your Jenkins job is allowed to send PR Checks, how do we tell it what to send?

That’s when these 3 plugins come into play:

• Checks API Plugin: This enables Jenkins to talk to the Checks API on various git hosting platforms, including GitHub, GitLab, and BitBucket. This is a base plugin that is meant to be extended with other plugins, not directly used by Jenkins jobs, though.

• GitHub Checks API Plugin: This enables Jenkins to talk to GitHub specifically. It extends the aforementioned Checks API Plugin.

• JUnit Plugin: This publishes JUnit-style XML test reports to various destinations. It posts to the current build, and — when the Checks API Plugin is available — publishes to GitHub/GitLab/…​ as PR Checks.

(Source of screenshot)

JUnit, you said?

Contrary to what the name implies, JUnit XML reports aren’t just for JUnit; it has been the de facto standard for reporting test results for various testing frameworks (and even for languages besides Java). Here are a few examples:

In Python, pytest has native support for creating JUnit XML format reports:

pytest --junitxml=path

In Go, the go-junit-report package can translate go test results to JUnit format:

go test-v 2>&1 ./... | go-junit-report -set-exit-code> report.xml

In C++, Google’s testing framework (GoogleTest) can emit test results as XML, which conforms to the JUnit format:

export GTEST_OUTPUT="xml:/path/to/junit.xml"# Run your normal test command here.

The JUnit format is described in this article, Common JUnit XML Format & Examples, along with some examples. You can also refer to the first 4 lines of the article Taking advantage of JUnit XML reports from Xray.

In summary, you can have the Jenkins job emit results in the JUnit XML schema, so that you can send the results as a PR Check via the JUnit Plugin.

To update the check at each step

The JUnit plugin is meant for the conclusions, but you might want to publish messages before it concludes. Depending on whether your Jenkins job can be naturally split into different build steps and be written in a Jenkins Pipeline, there are different ways to achieve this.

Case 1: If you can split your job into self-contained Steps, you can update PR Checks by interacting with the Checks API plugin directly. By "directly", I mean you don’t need to go through its "consumer plugins", such as the JUnit plugin. In Jenkinsfile syntax:

publishChecksname:'my-cool-check',title:'Integration Test',summary:'Manifest is built. Deploying to a staging pool now.',status:'IN_PROGRESS',text:'Nothing much to see here.',detailsURL:'https://link.to.your/jenkins/build/',actions:[]

This is useful when each action your job takes can be written as a standalone call to executables. For example, I may have a job that builds, tests, and publishes my Rust code by calling cargo build, cargo test, and cargo publish respectively. Since each step is a separate shell command, I can easily write them as:

// Under pipeline > stages > stage('...') > steps.script{publishChecksname:'my-cool-check',status:'IN_PROGRESS',title:'Build, Test, and Publish',summary:'Building...'sh'cargo build'publishChecksname:'my-cool-check',status:'IN_PROGRESS',title:'Build, Test, and Publish',summary:'Testing...'sh'cargo test'publishChecksname:'my-cool-check',status:'IN_PROGRESS',title:'Build, Test, and Publish',summary:'Publishing...'sh'cargo publish'}

To update the Check within a Step

Case 2: If your job is quite monolithic, it can be awkward to split your self-contained script into multiple, just for the sake of separating them as build steps and inserting publishChecks in-between. In these cases, you’ll have to directly interact with the GitHub API without the Jenkins layer. In terms of the fancy plugins, this means you even don’t have to use the Checks API plugin.

For GitHub Apps, the authorization & authentication process can be quite involved:

• Back when you installed your GitHub App to your repo, you granted a set of permissions to your App. This is called authorization. Exactly what your App can do to your repo can be retrieved from GitHub via an "Installation ID".

• When your script initializes, it needs to authenticate to GitHub as your App. To do so, the script needs a private key of the App. You can generate a private key from the App’s settings page and use it forever.

• If dealing with the raw GitHub API, the authentication is quite involved. First, you generate a JSON Web Token (JWT) with the private key. Then, you call a GitHub endpoint with this JWT, saying "I’m this App, and I’m trying to access the repos we agreed upon earlier." This endpoint gives you an "installation access token" (IAT). Your script would use this IAT to call other endpoints, just like how you’d use a PAT when calling endpoints manually as yourself.

Luckily, many languages have libraries that handle the intermediate work for you. Let’s say your Jenkinsfile runs a Python script via (sh './run.py'). We can use the PyGitHub library to call GitHub APIs Pythonically.

In Python, the built-in logging library is the standard way to emit messages. Your script creates a "logger" and attaches different "handlers" to it, each defining an output channel of your messages such as standard output, file on disk, or remote service. Intuitively, we can write a handler for logging to GitHub Checks.

With the help of ChatGPT, I implemented this handler. You can see that the handler requires quite some parameters to initialize. Where do you get them?

• For locating the PR and the commit, the GitHub Integration plugin can help. It can trigger Jenkins jobs upon PR events, injecting these environment variables to each Build. We’ll use two: GITHUB_PR_HEAD_SHA and GITHUB_REPO_SSH_URL.

• For referencing from the PR Check to the Jenkins Build, we’ll also need an environment variable set by vanilla Jenkins: BUILD_URL. On this page, you can find a list of all Jenkins-set variables.

• For authentication, we are on our own. We can upload the App’s private key to Jenkins credentials storage and wrap the sh './run.py' step with the closure sshUserPrivateKey. For the App ID and the Installation ID, since they aren’t necessarily secrets, we can afford to spell them out with an environment directive. Combined, your Jenkinsfile might look like this:

  pipeline{environment{GITHUB_APP_ID='123'GITHUB_APP_INSTALLATION_ID='456'}stages{stage('...'){steps{script{sshUserPrivateKey(credentialsId:"...",// ID from the Jenkins credentials storage.keyFileVariable:'GITHUB_APP_PRIVATE_KEY_PATH'){sh'./run.py'

Now, in your Python script, you can read the environment variables during initialization:

importloggingfromGitHubCheckHandlerimportGitHubCheckHandlerlogger=logging.getLogger('...')handler=GitHubCheckHandler(private_key_path=str(os.getenv("GITHUB_APP_PRIVATE_KEY_PATH")),installation_id=int(str(os.getenv("GITHUB_APP_INSTALLATION_ID"))),github_app_id=int(str(os.getenv("GITHUB_APP_ID"))),owner_repo=str(os.getenv("GITHUB_REPO_SSH_URL")).removeprefix("git@github.com:").removesuffix(".git"),commit_sha=str(os.getenv("GITHUB_PR_HEAD_SHA")),details_url=str(os.getenv("BUILD_URL")),)logger.addHandler(handler)

Then, you should be able to see Python logs directly in the PR Checks sections. Note that the yellow light besides your check will keep spinning as you send messages. To tell GitHub that this check has finished, you should call the handler.conclude(...) method. Therefore, you should keep the handler object exposed to your main function.

Summary

In this guide, we’ve explored how to automate and enhance PR quality assurance by tightening the integration between Jenkins and GitHub, specifically by emitting richer logs back to the PRs in a more timely manner.

With the missing link of the feedback loop filled, we boost developers' productivity. By freeing them from manually checking the results and attaching screenshots, we save developers' precious time and brain capacity, which can be devoted to more creative work.

In summary, automation not only boosts efficiency but also elevates the overall quality of your software development process. So, don’t hesitate! Start automating your PR quality assurance today and experience the benefits of a more streamlined and productive workflow.

Thank you for following along and happy coding!

Welcome Basil Crow - new Jenkins Governance Board member

December 7, 2023, 10:46 pm

≫ Next: Jenkins November 2023 Newsletter

≪ Previous: Log from Jenkins Jobs to GitHub Pull Requests as Checks

$

0

0

We would like to announce changes in the Jenkins Governance Board. There has been no election this year, because there was only one candidate per seat. Please welcome Basil Crow! At the same time, Oleg Nenashev retires from the board. We would like to thank Oleg for his contributions to the Jenkins project and the community. As a regular leader in GSoC, Jenkins Contributor Summits, and other community activities, Oleg has been a great fit for a governance board member. Thank you Oleg!

In addition to Basil’s inclusion in the Governance Board, our current officers will remain in their positions for another term. Thanks to all of the officers for continuing their service:

• Release Officer - Tim Jacomb

• Security Officer - Wadeck Follonier

• Events Officer - Alyssa Tong

• Infrastructure Officer - Damien Duportal

• Documentation Officer - Kevin Martens

Basil will join other governance Board Members: Kohsuke Kawaguchi, Alexander Brandes, Ullrich Hafner, and Mark Waite.

Basil’s term will last until December 2025.

About Basil Crow

Here is Basil’s statement from the elections:

I have been a Jenkins user since 2012, a contributor since 2014, a plugin maintainer since 2018, a core maintainer since 2021, and a GitHub organization administrator since 2023. I look forward to continuing to serve the Jenkins community in my new role as a board member.

My vision involves leading the design and implementation of community-wide projects while also actively supporting the board in executing the various administrative and operational tasks that are needed to sustain the Jenkins project and community. The values of the Jenkins community have always resonated with me, and I am eager to continue championing them.

As the Jenkins project nears its 19th birthday, it stands as a testament to the resilience of open source communities. Much like cities, these communities can be small yet vibrant, serving a critical role to their constituencies. I look forward to ensuring that the Jenkins project not only survives but thrives, providing sustained value to its dedicated users and contributors for years to come.

What’s next for the Jenkins Governance Board?

In February we host a Jenkins Contributor Summit, the day before FOSDEM. It is a day-long event featuring presentations on the "State of Jenkins", Project/SIG updates, discussion on various key projects, "Ignite Talks", and demos.

Don’t hesitate to reach out if you want to submit a presentation, talk, or demo!

Participating in Jenkins Governance

Jenkins Governance Board has just a representative function in the community. The project and the community have a long history of open and inclusive governance driven by many contributors. We invite all community members to participate in the project by joining the governance meeting, participating in the mailing list conversations, and joining special interest groups driving particular topics.

Please refer to the participation page to learn more about contributing to Jenkins in general.

Jenkins November 2023 Newsletter

December 13, 2023, 11:51 am

≫ Next: 2024 Jenkins Contributor Summit - Update

≪ Previous: Welcome Basil Crow - new Jenkins Governance Board member

$

0

0

Key Takeaways

• Basil Crow joins the Jenkins Governance Board.

• A Jenkins Contributor Summit will be held prior to FOSDEM.

• The Contributor Spotlight site is now live.

Contributed by: Mark Waite

Basil Crow joins the Jenkins governance board in December 2023. He’ll serve for a two-year term. Thanks to Basil for his willingness to serve. More details of the 2023 governance board and officer changes are available in a blog post by Alexander Brandes.

Jenkins 2.426.1 was released on November 15, 2023 with many improvements and additions. Darin Pope and Mark Waite reviewed the Jenkins 2.426.1 features in a 50 minute webinar. Key items include:

• Java 21 support

• Java 17 or Java 21 recommended

• Prototype.js JavaScript library removed

• Drop support for Red Hat Enterprise Linux 7 and its derivatives like CentOS 7

A Jenkins Contributor Summit will be held in Brussels, Belgium on Friday, February 2, 2024. We’ll gather for a day of presentations, planning, and working on the future of Jenkins. Immediately after the Contributor Summit, FOSDEM 2024 will be a two day conference focused on open source. Jean-Marc Meessen is gathering agenda topics and attendees on the community site.

Contributed by: Damien Duportal

Microsoft has donated $40,000 USD to the Continuous Delivery Foundation for use in member projects. The Jenkins project is pleased to be using those credits to reduce CDF expenses.

The AWS cost reduction project has a working prototype that is using Cloudflare R2 and the Jenkins mirror system to reduce bandwidth costs. We plan to complete the Jenkins Enhancement Proposal, a prototype temporary transition, and the production transition by January 31, 2024.

Contributed by: Mark Waite

Jenkins 2.426.1 provides a new “Appearance” page so that administrators have a single page to configure the Jenkins theme and other user interface details. Thanks to Tim Jacomb for the Appearance page.

Jenkins 2.426.1 also updates the Jenkins user experience with confirmation dialogs inside the pages instead of using the web browser’s confirmation dialog. Thanks to Markus Winter for the implementation of those dialogs and for the API that allows plugins to do the same.

Keyboard navigation has been improved in Jenkins 2.426.1 as well. Users can now access tab panes by keyboard navigation.

Contributed by: Bruno Verachten

• Java 21 support

  • The Jenkins enhancement proposal by Mark Waite is progressing nicely.

  • Progress of testing the top plugins with Java 21:

    • 108 of the top plugin repositories passing tests with Java 21.

    • 20 of the top plugin repositories not yet passing tests with Java 21.

  • The Infrastructure team finished the transition to official 21.0.1+12 Linux (17 on Windows).

  • All agents and controllers now supply a JDK21 or JDK21 preview Docker image.

• Java 17 is now the default Java version used in the Docker images, even for the LTS and Windows:

  • If you don’t use a tag specifying the JDK version like 2.429-jdk11, but shorter tags like 2.429, you will end up with an image using JDK17 and not JDK11 anymore.

• OS support:

  • CentOS 7 container images have been removed, starting from the 2.432 release.

• ARM64:

  • More services in the infrastructure have migrated to a new ARM64 nodepool.

Contributed by: Kevin Martens

The Contributor Spotlight is a new location where we will be highlighting the top contributors to Jenkins. We have been gathering and measuring data to determine who would be part of this group, and then reached out to everyone to collaborate and capture their stories. Thanks to all of the contributors who have collaborated with us on this project thus far, and all those who we will be working with going forward as well. We’ll be publishing new Contributor Spotlights every two weeks, to provide space for the current spotlight to shine and leave room for other announcements or news. Thanks to Alyssa Tong, Bruno Verachten, Jean-Marc-Meessen, Kris Stern, Hervé Le Meur and Cristina Pizzagalli for their work in gathering the data, designing the site, getting the site into production, and offering guidance along every step of the way.

November had four blog posts, including the Jenkins Contributor summit at FOSDEM announcement, the 2+2+2 Jenkins Java support plan, and the announcement of the Contributor Spotlight site.

2024 Jenkins Contributor Summit - Update

January 17, 2024, 10:45 am

≫ Next: Jenkins 2023 Recap

≪ Previous: Jenkins November 2023 Newsletter

$

0

0

The Jenkins Contributor Summit, being held in Brussels on February 2nd, is now quickly approaching. We are looking forward to meeting you.

If you plan to join us and didn’t let us know yet, don’t forget to register by dropping us a note. The list of registered attendees can be found in this document: Contributor Summit 24 - Attendees.

The Summit will take place at Betacowork, located at 4 Rue des Pères Blancs, 1040 Brussels, Belgium (Betacowork on Google Maps) in the "AZZAR" room.

The following list provides a quick overview of the day’s planning:

• We will welcome attendees from 9h30 (9:30 AM) on.

• The Summit will start at 10h00 (10:00 AM).

• During the morning, we will listen to the introduction presented by the various Jenkins Officers. Each one will present, for their domain of responsibility, the year’s projects and goals, the challenges, as well as the topics that could/should be discussed during the Summit.

• At 12h00 (12:00 AM) we will have a one hour lunch break, where people can go grab some food (sandwiches) at a nearby shop.

• At 13h00 (1:00 PM), we start the afternoon sessions and discussions:

  • Changes made to Jenkins to support the new CloudBees high availability solution (Vincent L.)

  • Impact and challenges of removing Blue Ocean of the base Jenkins distribution (Alexander B. & Damien D.)

  • User experience evolution

  • Initiatives and roadmap discussion (as built during the morning sessions).

This will lead us to 16h30/17h00 (4:30/5:00 PM) for the end of the presentations and discussions.

Until 18h30 (6:30 PM), we will have one or several (concurrent) coding “workshops”/discussions/demonstrations (still to be discussed and organized with Basil Crow). People not interested in these sessions can either network or head to their respective hotels for a quick break.

At 18h30 (6:30 PM), we will head for the restaurant (“Restaurant Rubens”, Rue de l’Escadron 21, 1040 Bruxelles, Belgium) that is a 12 minute walk from the co-work. At 19h00 (7:00 PM) we will have dinner.

---

Jenkins 2023 Recap

January 25, 2024, 11:43 pm

≫ Next: Collaboration is Key - Making the Open-Source Community Safer for Developers

≪ Previous: 2024 Jenkins Contributor Summit - Update

$

0

0

Contributed by: Wadeck Follonier

The Jenkins Security team has multiple missions, with the most visible to users being the publication of advisories.

In 2023, the team published 17 advisories: 4 included Jenkins core, and 13 were solely about plugins. In total, 211 vulnerabilities were announced.

In terms of reporting trends, we have seen an increase in people reporting CVEs originating from dependencies. Our position on this issue is that when analyzing CVEs, if they are impacting we correct them and publish an advisory; otherwise, we publish a blog post only for the most popular ones, such as Spring4Shell or Log4Shell. With dozens of CVEs published every month, we prefer not to publish information for each one unless it is relevant.

To reduce the occurrence of those issues and provide reporters with a point of reference, we have updated the security policy in Docker.

We would also like to extend our gratitude to the GitHub Security Lab for reporting 27 vulnerabilities through their CodeQL rules and for their collaborative efforts in both the analysis and the enhancement of our tools.

The team does not rely solely on “external” security researchers to find vulnerabilities; a considerable amount of time during the year is spent on proactively auditing the code. This year was marked by some specific research areas: OAuth flow and disabled SSL validation, in addition to the usual CSRF, XSS, or XXE vulnerabilities.

Additionally, we have expanded the scope of our security reviews for Pull Requests, particularly in Jenkins core. Approximately 70 PRs were labeled as “security-approved”. This proactive measure allowed the team to prevent the introduction of some vulnerabilities, which is significantly less costly than addressing them after they have been incorporated into the production code.

As part of our mission, raising community awareness about security is also a key factor in reducing the introduction of vulnerabilities at an early stage. In this regard, we welcomed Andrea to our security team for a summer internship from June to August. By the end of it, he had successfully reported 28 vulnerabilities. For more information about his internship, you can read his blog post.

Education and tooling are closely related for us. We are investing time to propose new security automation and to improve our existing tooling. This year, we introduced the existing CodeQL ruleset for hosting requests. This provided future maintainers with detailed explanations of the findings. Along with this effort, we also enhanced our security scan by supporting warning suppression through code annotation.

Continuing with tooling improvements, we added a beta feature to the bot present in SECURITY tickets, allowing maintainers to block or unblock releases of their plugins. The intent of this feature is to reduce the likelihood of an involuntary release when one is staged in private for a future advisory.

We also introduced the possibility of having an exclusive CD mode. This option allows maintainers to force all releases of their plugins to be done through the official CI, reducing the risk related to their laptops being compromised.

Nowadays, AI is everywhere. For security, it’s often a bit more complicated due to the aspect of confidentiality. To circumvent this while still delving into the topic, we have been using OpenAI API since October to triage the new JENKINS tickets. It’s the public tracker for Jenkins, but sometimes, vulnerability reports are wrongly submitted there. AI has helped us detect whether something is security-related and thus expands our scope without needing to monitor everything. This approach has proven to be quite successful after three months.

Along with other small projects, we continue to work on more long-term/background projects, such as the introduction of the Content-Security-Policy header. Throughout the year, we made significant progress in covering the core usage of inline JavaScript.

Contributed by: Mark Waite

Jenkins is a project of the Continuous Delivery Foundation. We’re grateful for the many different ways that the Continuous Delivery Foundation supports the Jenkins project. They provide financial support for Jenkins infrastructure, promotional support for Jenkins initiatives, infrastructure support for the Jenkins issue tracker, and consultation on many other topics. The Jenkins project was well represented at cdCon 2023 and at cdCon Japan.

Contributed by: Damien Duportal

Infrastructure costs decreased by 21% in 2023 while usage increased. Jenkins use is increasing worldwide and Jenkins infrastructure continues to meet the growing needs.

Jenkins infrastructure broadened its operating environments in 2023 by expanding its use of ARM64 processors to reduce costs. Additional software improvements were implemented in the Jenkins Pipeline to reduce costs while maintaining reliability.

Costs were further reduced by the Artifactory bandwidth reduction project. We’ve gone from 50 TB per month to 15 TB per month of artifact repository bandwidth use, thanks to help from JFrog and implementations of artifact caching proxies by the infrastructure team.

We’re grateful for donations from our organizational sponsors like CloudBees, the Continuous Delivery Foundation, and the Linux Foundation and for our infrastructure sponsors including GitHub, JFrog, Atlassian, Microsoft, DigitalOcean, Netlify, PagerDuty, Discourse, Datadog, and Cloudflare. We deeply appreciate the mirror providers around the world like Oregon State University Open Source Lab, Tsinghua University, XMission, Yamagata University, Servana, Belnet, and RWTH Aachen University.

Contributed by: Mark Waite

The badly outdated and unmaintained Prototype.js JavaScript library has been removed from Jenkins core and from over 50 Jenkins plugins. Special thanks to Basil Crow and Tim Jacomb for their work to identify and replace Prototype.js references in Jenkins JavaScript.

User interface look and feel improvements continued throughout 2023. Improvements were delivered in forms, menus, and pages. Menus are easier to navigate and easier to understand.

Multiple improvements were released for the Jenkins management pages, including the new “Appearance” page that makes it easier to use Jenkins themes. Forms, pages, and menus have all been enhanced in 2023.

Navigation of cloud management pages is simpler and clearer thanks to layout and navigation enhancements.

Hundreds of user interface improvement pull requests have been merged this year. Thanks to all those contributors!

Contributed by: Bruno Verachten

The year 2023 has been a significant period for the Jenkins project, marked by notable advancements and achievements. The community as a whole has played a crucial role in shaping the project’s trajectory.

Software Versions

• Jenkins Core: The project witnessed multiple Jenkins Core releases, featuring advancements in stability, security, and added features. Notable releases include Jenkins LTS2.426.2 and weekly releases, reflecting our commitment to both stability and innovation.

• Java Versions: The transition to Java 17 and subsequently Java 21 marked a significant step forward. The community diligently tested the top 250 plugins with Java 21, showcasing the project’s adaptability to evolving technologies.

• Java Support Plan: The proposal and discussion around the 2+2+2 Java Support Plan demonstrated a strategic vision for the project’s future. This aligns with industry standards, ensuring long-term sustainability.

• Dependency Updates: Components throughout the Jenkins project were updated in 2023, including operating systems, libraries, and tools. We also made essential transitions, such as moving to Debian Bookworm, the latest Alpine version, and implementing an end-of-life warning. This helps users know when they need to upgrade their OS or Java version. Additionally, we officially declared the end of life for Jenkins support of Red Hat Enterprise Linux 7 and derivatives like Centos 7 and Amazon Linux 2.

Docker Images and Containers

• The transition to using OS-based images and installing JDK from binaries in some instances, rather than relying solely on Temurin images, highlighted our adaptability to evolving best practices.

• Now, all Docker images are available with a version of Eclipse Temurin JDK21.

• We expanded our platform support to include amd64, aarch64, s390x, windows/amd64, and even armv7 for some images.

• Regular dependency updates were a focus in 2023:

• Docker agent received 205 pull requests.

• Inbound agent saw 132 pull requests.

• Docker ssh-agent had 139 pull requests.

• Docker had 219 pull requests.

Expanded Compatibility Testing

The Jenkins project added over 90 plugins to the compatibility testing suite that is part of our plugin bill of materials. The most popular Jenkins plugins are regularly tested in a Jenkins configuration with hundreds of other plugins.

These updates and transitions underscore our commitment to providing a robust and adaptable platform for our users.

Contributed by: Kevin Martens

Throughout 2023, the Jenkins site and documentation saw several changes from returning and new contributors. Over the course of 12 months, the site had a total of 843 pull requests merged, 67 blog posts from 21 different authors, and 98 plugin wiki migrations completed. These pull requests and blog posts covered everything from minor adjustments and refinements to major announcements regarding Jenkins and everything in between.

Some of the notable changes that happened were:

• The addition of the Platform Information section, which contains Java information and Jenkins support policies.

• The Plugin Health Score is now visible on https://plugins.jenkins.io/, providing users insight into the health of plugins in the Jenkins ecosystem.

• The Books page was updated with new additions & formatting.

• The Contributor Spotlight page was launched to highlight the heaviest contributors to Jenkins. The goal is to appreciate and showcase the talent and hard work that goes into keeping Jenkins working behind the scenes.

  • This was done in collaboration with the Outreach & Advocacy SIG.

Several enhancements to Jenkins.io for mobile users were implemented so that regardless of platform, everyone can access and read every screen. Additionally, there is a new layout for the blog, where each post is displayed as a card.

There was also the addition of UpdateCLI to the jenkins.io repository. This has helped ensure that whenever new versions of Jenkins are released, the documentation is updated accordingly. Thanks to Bruno Verachten for his work on getting this configured and added.

The Google Summer of Code participants also provided various contributions to both Jenkins core and Jenkins.io, sharing their experiences and insights with the community.

In the coming year, we are also planning on implementing a versioned documentation site, where users will select which Jenkins LTS version they are using and see the corresponding documentation. This is the result of a Google Summer of Code project originally looking at alternative build tools for jenkins.io. Thanks to Kris Stern and Vandit Singh for all their work on this.

Contributed by: Alyssa Tong

In 2023, through the collaboration and contributions of new and existing community members from around the globe, the Jenkins project successfully completed the following projects for the betterment of Jenkins:

• The launching of a new site, contributors.jenkins.io, is dedicated to highlighting top Jenkins contributors who are dedicating their time and talent to shape the future of Jenkins.

• Participated in Google Summer of Code 2023

• Welcomed 80+ new contributors with over 400 pull requests merged in Hacktoberfest 2023

• Participated in five DevOps World locations, with community speakers

  • Tim Jacomb - London

  • Olivier Lamy - Singapore

  • Mark Waite - New York, Chicago, and Santa Clara

Along the way, Jenkins won the DevOps Dozen Most Innovative DevOps Open Source Project award for 2023!

The Jenkins project is also excited to share what’s to come in 2024:

• Jenkins in GSoC 2024: Call for Project Ideas + Call for Mentors.

  • A Guide for Mentors is a great resource for potential GSoC mentors, who want to give back to the community through the act of mentorship.

• Contributor Summit at FOSDEM: A day-long event featuring updates on the "State of Jenkins", Projects/SIGs, discussion on various key projects, and demos (Feb 2, 2024).

• FOSDEM'24: Jenkins will have a devstand at FOSDEM (Feb 3-4, 2024).

• SCALE 21x: Jenkins will have a booth presence at SCALE (March 14-17, 2024)

Jenkins Momentum

In August, we worked together with the Linux Foundation and the CloudBees communications teams to report out on achievements of the Jenkins project. We highlighted growth in Jenkins jobs, along with the vibrant contributor community and impressive community sponsors. Jenkins still enjoys an estimated 44% market share and is a critical part of the IT infrastructure enabling organizations to automate their CI/CD processes.

Specifically, as reported in the news release and from the community stats:

• Monthly Jenkins Pipeline jobs defined grew 79% during the period June 2021 – June 2023, from 27,105,176 jobs per month to 48,625,398 jobs per month. Jenkins Pipeline jobs are used to build out CI/CD software delivery automation flows, or software pipelines. Growth in this job type is a leading indicator of CI/CD adoption and, specifically, the pervasiveness of Jenkins-based CI/CD.

• Total monthly jobs rose 45% from June 2021, when 50,785,205 jobs per month were defined, to June 2023 when 73,746,418 jobs per month were defined. Growth in the total monthly workload (all Jenkins jobs) further demonstrates the expansion of Jenkins usage within organizations.

The news release also called out the 600 active contributors the Jenkins project has, along with sponsors such as GitHub, Atlassian, AWS, CloudBees, Datadog, DigitalOcean, Discourse, Fastly, GitHub, IBM, JFrog, Netlify, PagerDuty, and Sentry.

Many THANKS!

The Jenkins project consists of more than 2000 plugins and components which are maintained and developed by thousands of contributors from around the globe. Thanks to them, a lot of improvements happen in the project every day. We are grateful to everybody who participates in the project, regardless of contribution size. Every bit makes a difference: new features, bug fixes, documentation, blog posts, well reported issues, Stackoverflow responses, etc.

MANY THANKS FOR ALL YOUR CONTRIBUTIONS!

Here’s looking forward to many more exciting accomplishments to come in 2024!

Collaboration is Key - Making the Open-Source Community Safer for Developers

January 25, 2024, 11:43 pm

≫ Next: Nominate Someone – 2024 Jenkins Contributor Awards

≪ Previous: Jenkins 2023 Recap

$

0

0

Who is Sonar?

Sonar is a code quality and security tool that helps developers write Clean Code. Sonar analyzes code for issues that lead to unreliable, unmaintainable, and insecure software at two points in the development lifecycle - first, when the developer initially writes code in the IDE with SonarLint and, again, as part of the Continuous Integration (CI) pipeline before the code is sent for release with SonarQube or SonarCloud.

To keep up with the latest cyber security trends and better understand emerging threats, the dedicated research team at Sonar finds and inspects vulnerabilities in modern open-source applications; we incorporate all of our insights into our products (SonarLint, SonarQube, SonarCloud).

In our endeavor to help secure open-source projects and improve, our research team decided to take a look at the Jenkins project.

Why Jenkins?

Before we get started, we’d like to thank the Jenkins team for their fast response, dedicated effort to getting this fixed, and transparency throughout the disclosure process. Okay, let’s get into it…

We saw this research as an excellent opportunity - and a challenging one, because Jenkins is highly popular, well-maintained, and has a great community. Given the broad adoption and usage of Jenkins by the community, we felt it is important to analyze the security of this code base, and if we were to find a vulnerability, it would not only help the users of Jenkins but also help us better understand and improve the security capability of our solutions.

From a research perspective, ignoring the impact aspect, going into well-maintained code is a double-edged sword. On the one hand, the code has less potential for security vulnerabilities and poses a bigger challenge for finding bugs. On the other hand, because it is easily understandable code, in addition to the well-written and thorough documentation, the researcher can progress quickly and assess the project better.

What is our research approach, what did we look at in Jenkins?

Our initial research approach is more or less identical for each project. First, we try to understand the project from a user’s perspective. In the case of Jenkins, this was made easy due to the well-documented “Jenkins Handbook” and the large community that already tackled many issues and questions on the internet.

Following that, we started debugging and getting our hands dirty. Slowly but surely we got a good grasp on the architecture of Jenkins, from how the project “staples” an endpoint to a function to the authorization methodology, authentication methods, the intended behavior of various features, and more. With this better understanding of the technical internals, we can switch to an attacker’s perspective and think of the possible attack scenarios. Which endpoints can an unauthorized attacker reach? What can a limited authorized attacker do? Is a feature doing more than intended?

What was the outcome?

One of the important mindsets of a security researcher is to know when to give up and when to stay stubborn. Our findings were not easy to catch. Jenkins code quality is superb making it less likely to have security vulnerabilities. But, with our persistence, we noticed a niche feature that used third-party, unmaintained code, which allowed us to disclose sensitive information. Usually, the feature exploited requires specific permission to execute, but due to an exception thrown before the intended behavior, the sensitive data (which was exported from the third-party code) was leaked, enabling an attacker to have a serious impact on a Jenkins instance.

From Sonar’s point of view, we have analyzed the complex call graph and found unique ways to improve our engine. On top of that, it clarified for us the importance of deeper SAST, a feature that enables developers to automatically discover and fix code security issues arising from interactions between user source code and third-party, open-source libraries.

We were excited to have this opportunity to collaborate with the Jenkins team, while also making the open-source community safer and providing a technical blog post for educating the security expert audience. Throughout the disclosure process, we were met with an impressive level of professionalism and kindness that made all of this happen.

More about Sonar and Clean Code

At Sonar, we’re dedicated to enabling developers to create Clean Code— code that is consistent, intentional, adaptable, and responsible. We believe that code quality and security go hand in hand. By focusing on Clean Code best practices, it is easier to avoid mistakes that lead to vulnerabilities in code. Our Clean as You Code approach ensures that code stays consistently clean avoiding the introduction of bugs and security vulnerabilities from the start with the quality of the codebase being optimized as code is added or changed.

Nominate Someone – 2024 Jenkins Contributor Awards

January 31, 2024, 5:43 pm

≫ Next: Google Summer of Code 2024… Here We Come!

≪ Previous: Collaboration is Key - Making the Open-Source Community Safer for Developers

$

0

0

Jenkins Contributor Awards for 2024 are being run by the Continuous Delivery Foundation (CDF) along with many other CDF Community Awards.

The nominations are open and are being accepted using GitHub issues to make the process transparent. Any contributor is eligible! The deadline to nominate someone is February 19, 2024. Voting will open on February 22.

Nominate contributors or vote with reactions/comments for all three Jenkins awards:

• Most Valuable Jenkins Contributor

• Most Valuable Jenkins Advocate

• Jenkins Security MVP

The winners will be announced at cdCon 2024 on April 16 - 18, 2024.

You can also nominate Jenkins community members for global awards like "Top CDF Ambassador", "Top CDF Contributor", or "Top CDF End User"! For all CDF Community Awards and more details, visit the CDF Award Page.

Google Summer of Code 2024… Here We Come!

February 24, 2024, 3:43 am

≫ Next: Jenkins Contributor Summit and FOSDEM Recap

≪ Previous: Nominate Someone – 2024 Jenkins Contributor Awards

$

0

0

We are thrilled to announce that Jenkins has been accepted to Google Summer of Code 2024! This will be Jenkins' eighth year as a mentoring organization.

Congratulations to all 195 accepted open-source organizations!

As a mentoring organization for the past seven years, Jenkins has mentored 35 GSoC students by 85+ different mentors, bringing together over 110 strangers for a common idea - Jenkins!

At the heart of it, GSoC is more than just a mentoring program. The intention is to welcome and engage with new contributors in open source. It is about giving a little of your day to make a lifetime of difference, not only for the GSoC contributors, but also for the many Jenkins users who will benefit from the improvements.

We are excited to welcome new GSoC contributors to the Jenkins family. We think you will enjoy this valuable experience while developing your technical skills. You will gain insights into how the community works. The best part will be learning from people who are passionate about Jenkins and, more importantly, they are passionate about wanting to make a difference for another individual (GSoC contributors) and for the betterment of the project as a whole.

For detailed information on Jenkins GSoC 2023, please refer to the completed projects.

What’s next?

GSoC officially announced the accepted mentor organizations, so please expect more potential GSoC contributors to contact projects in our Gitter and Discourse channels. Many communications will also happen in SIG and sub-project channels. We will be working hard to help potential participants to find projects that align with their interests, explore the relevant domain(s), and to prepare their project proposals before the deadline on April 2nd (UTC). Then, we will process the applications, select projects, and assign mentor teams.

All information about the Jenkins GSoC is available on its sub-project page.

How do I apply?

Refer to the information for contributors page for full application guidelines.

We encourage interested participants to reach out to the Jenkins community early and start exploring project ideas. We also encourage participants to join the weekly Jenkins GSoC office hours. These meetings are for participants to meet org admins and mentors and to ask questions. Also, be sure to join our Gitter channel and Discourse server to receive information about such incoming events in the project.

The application period starts on March 18th (UTC), but you should prepare now! Use the time before the application period to discuss and improve your project proposals. We also recommend familiarizing yourself with Jenkins and exploring your proposal areas. Project ideas include quick-start guidelines and reference newbie-friendly issues, which may help with your initial study. If you do not see anything interesting, you can propose your own project idea.

I want to be a mentor. Is it too late?

It’s not! We are looking for more project ideas and for Jenkins contributors or users who are passionate about Jenkins and want to be a mentor. No hardcore experience is required, as mentors can study the project internals together with GSoC contributors and technical advisors.

You can either propose a new project idea or join an existing one. The call for mentors blog post and information for mentors page have additional information on being a mentor. If you want to propose a new project, please do so as soon as possible so that potential GSoC contributors have time to explore them and prepare their proposals.

This year, mentorship does NOT require strong expertise in Jenkins development. The objective is to guide participants and get involved in the Jenkins community. GSoC org admins will help find advisors if special expertise is required.

Important dates for GSoC 2024

• February 22 - March 18 - Potential GSoC contributors discuss application ideas with mentoring organizations. Show us your proposal!

• March 18 - The GSoC contributor application period begins.

• April 2 - The GSoC contributor application deadline.

• May 1 - Accepted GSoC contributor projects are announced.

• May 1 - May 26 - Community Bonding Period | GSoC contributors get to know mentors, read documentation, and get up to speed to begin working on their projects.

• May 27 - Coding officially begins!

• July 8 - The Midterm evaluation deadline.

• August 19 - August 26 - Final week: GSoC contributors submit their final work product.

• September 3 - Initial results of Google Summer of Code 2024 are published.

• November 4 - Final date for all GSoC contributors to submit their final work product.

Refer to the GSoC Timeline for more info.

Jenkins Contributor Summit and FOSDEM Recap

February 28, 2024, 11:13 am

≫ Next: GSoC 2024 contributor application ended. What happens next?

≪ Previous: Google Summer of Code 2024… Here We Come!

$

0

0

The previous in-person Jenkins Contributor Summit took place in 2020, just prior to the lockdowns and precautions that would change the world. Thankfully, on February 2, 2024, just prior to this year’s FOSDEM conference, we were able to gather again, in Brussels, so that we could have an in-person Jenkins Contributor Summit.

The return to in-person meant that not only could we gather in one location, but we were also able to collaborate and work together directly, something that is not normally possible due to the global spread of the Jenkins community. To make things even better, all of the Jenkins Officers and four of the five board members were able to travel to Brussels for the summit!

Massive thanks to Betacowork for providing a space that could hold the Contributor Summit.

If you want to follow along, we are including a link to the Contributor Summit slide deck to view the presentation at any time.

The day started with Jean-Marc Meessen providing an overview of the agenda.

Mark Waite then provided a review of the current state of Jenkins as a project. This covered everything from user and maintainer statistics to what the future of Jenkins will hopefully look like.

Following Mark, the Jenkins SIG leaders and Officers provided insights into their various areas of knowledge.

Damien Duportal, the Infrastructure Officer, presented first, reviewing how Jenkins Infrastructure has evolved over the last year and what we are looking forward to in 2024.

Next up was Tim Jacomb, the Release Officer, shared the successes and innovation that the project has experienced throughout 2023.

After Tim wrapped up his section of the presentation, Kevin Martens, the Documentation Officer, shared what we hope 2024 will look like for Jenkins documentation and Jenkins.io.

As the Advocacy & Outreach SIG leader, Alyssa Tong then recapped all of the events that Jenkins held or participated in during 2023.

She also shared the exciting news that Jenkins has recently been won the Most Innovative DevOps Open Source Project award from DevOps Dozen

Following Alyssa, Wadeck Follonier, the Security Officer, reviewed the successes that the Jenkins Security team had over the last year. Wadeck also outlined tooling additions and changes to Jenkins that will help determine vulnerabilities and issues.

Tim Jacomb then took the stage once again to provide insights on the user experience of Jenkins. He highlighted items such as the Plugin Manager improvements, UI modernization, and the work that Jan Faracik has contributed such as removing the Yahoo UI, among other things.

After taking some time to break for lunch, we returned to the contributor summit to hear Vincent Latombe sharing what was done in Jenkins to support High Availability/Horizontal Scalability for CloudBees.

After Vincent finished, Oleg Nenashev provided an update and shared what the roadmap looks like for Jenkinsfile Runner.

After Oleg wrapped up, Bruno Verachten provided insights and review from the Platform SIG.

Once Bruno finished his presentation, Alexander Brandes and Damien Duportal shared and discussed the idea (and potential challenges) of removing Blue Ocean from the Jenkins base distribution.

This is a topic that will continue to be discussed for the foreseeable future, until a reasonable solution and replacement can be decided upon.

After all of the presentations were finished, Basil Crow provided an overview and demo for Searching for API usage in plugins.

The presentation itself reviewed what the API usage might include, why it is helpful to perform this search, why migrations should be managed, and why empathy is a core value when it comes to development and engineering.

The Contributor Summit then concluded with a two hour group coding session, where attendees were encouraged to work with other members of the summit to work on any of the topics that were discussed prior. This provided an opportunity for people to work directly with one another, which would otherwise be impossible due to how far the Jenkins community stretches. Work that would typically be done asynchronously was instead immediately possible thanks to the proximity of the contributors.

Now, with the Contributor Summit wrapped up, we shifted focus to FOSDEM and the rest of the weekend.

This year’s FOSDEM conference was as busy as ever!

The Jenkins booth saw tons of visitors over the two days, and we even sold out most of our t-shirts! Bruno once again brought miniJen and a whole new Kubernetes (Roundernetes) set-up to help draw visitors in and have conversations around what Jenkins is capable of.

Over the course of FOSDEM, we received hundreds of visitors, evident by the lack of stickers that we brought home. There was very little downtime at the Jenkins stand, with visitors constantly coming by with questions about Jenkins present and future.

Overall, the Contributor Summit and FOSDEM were both wildly successful for the Jenkins community, proving again how important these events are.

Thanks and gratitude

We want to share our deep appreciation to Betacowork for providing a room for the Jenkins contributor summit. The room was more than enough for all of the contributors to gather and share in the summit, in addition to providing great space for the group coding session. Thanks to Jean-Marc Meessen for connecting with Betacowork to secure the room for this year’s summit.

We also want to thank FOSDEM for once again allowing Jenkins to be part of the event. It was a wonderful experience to attend the conference and share Jenkins with the open-source community.

We would also like to thank both CloudBees and the Continuous Delivery Foundation for donating the shirts, socks, and stickers that occupied our booth for the weekend.