Java 17 Preview is available in Jenkins 2.339+

March 22, 2022, 1:42 am

≫ Next: Jenkins Contributor Awards - Nominations Open

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

$

0

0

Please refer to the Running Jenkins on Java 17 documentation for up-to-date details on how to run Jenkins on Java 17.

Jenkins, one of the leading open-source automation servers, does not yet officially support Java 17. On September 14, 2021, OpenJDK 17 was released. This is a Long-Term-Support (LTS) release, and it will stay around for years. The Jenkins project is eager to offer full support of this version. Over the last year, many contributors have been working toward enabling support for Java 17 in the project. It was a thorny path, but now, on behalf of the Jenkins Platform SIG, we are happy to announce preview availability of Java 17 support in Jenkins weekly releases!

Why do we need preview availability for Java 17? It offers Jenkins contributors and early adopters a way to try out the changes before the general availability release happens later this year. It should help us to get more exploratory testing and, hopefully, resolve most of the issues before Java 17 is officially supported in Jenkins.

In this blog post we will describe how to run with Java 17 and how to investigate and report compatibility issues.

Background

A group of contributors has been working on Java 17 support, focusing on enabling Java 17 support in development tools, testing, and addressing known compatibility issues. See the Platform SIG meeting notes for detailed status updates. Starting with Jenkins 2.339, Jenkins successfully runs with latest OpenJDK 17 releases on various Linux and Windows platforms. We performed a lot of automated and exploratory tests. Jenkins plugins appear to work well. There is ongoing test automation effort toward the GA release, but we were able to successfully run Jenkins core tests and Plugin Compatibility Tester for recommended plugins.

Running Jenkins and Java 17 in Docker

For several months, we have provided Docker images for the Jenkins controller and agent. All these images are based on the official Debian stable and Eclipse Temurin images maintained by the Docker community.

Jenkins controller image

Java 17 support is now provided as a part of the officialjenkins/jenkins image. You can run Jenkins with Java 17 simply as:

docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:jdk17-preview

The following tags are available:

jdk17-preview

Latest weekly release with Java 17 support

2.339-jdk17-preview

Weekly releases packaged with Java 17

The image is fully compatible withthe official Jenkins Docker image documentation, e.g., you can use plugins.txt to install plugins, mount volumes, and pass extra options via environment variables.

Agent images

If you use containerized agents via the Docker or Kubernetes plugins, we have also released official Docker images for Jenkins agents:

• jenkins/agent

• jenkins/inbound-agent

All images use the jdk17-preview tag.

Running Jenkins with Java

As with Java 11, you can start Jenkins using the java command:

java -jar jenkins.war --enable-future-java

Compatibility issues

In March 2022, the community performed many exploratory tests to discover as many Java 17 issues as possible.

As a result, the community solved a lot of problems before announcing Java 17 support in Jenkins. However, it is still possible that some plugins have not been updated to support Java 17.

If you find a regression in a plugin, please file a bug report in Jira:

• Open Java 17 issues

For security issues, please use the standard vulnerability reporting process. Although we will be fixing Java 17 specific issues in public while Java 17 support is in preview, following the security process will help us to investigate the impact on Java 8 and 11 users.

Contributing

We appreciate any and all contributions in the Java 17 effort, including trying out Jenkins with Java 17 and reporting or fixing compatibility issues.

• If you want to do exploratory testing, we recommend trying out Java 17 support on one of your test controllers. Such testing is highly appreciated, especially if you use some service integration plugins or exotic platforms.

• If you are a plugin developer/maintainer, we would appreciate if you could test your plugin with Java 17. Java 17 developer guidelines are forthcoming.

Whatever you do, please let us know about your experience by sending a message to the Platform SIG mailing list. This information will help us track changes and contributions. Any other feedback about the migration will be appreciated!

What’s next?

We will soon be updating the toolchain to support Java 17. At that point, we will publish documentation for plugin developers explaining how to test plugins with Java 17.

In the coming weeks we will focus on addressing feedback from early adopters and fixing any discovered compatibility issues. We will also continue working on Java 17 support patches toward general availability later this year.

Links

• Platform Special Interest Group

---

Jenkins Contributor Awards - Nominations Open

March 22, 2022, 8:12 am

≫ Next: Linux installation packages migrated from System V init to systemd

≪ Previous: Java 17 Preview is available in Jenkins 2.339+

$

0

0

Jenkins Contributor Awards for 2022 will be run by the Continuous Delivery Foundation (CDF) along with many other CDF Community Awards.

The nominations are currently open and are being accepted using GitHub issues to make the process more transparent. Any contributor is eligible! The deadline to nominate someone is March 29, 2022. Voting will open in April.

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 2022 on June 7.

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.

Linux installation packages migrated from System V init to systemd

March 26, 2022, 6:12 pm

≫ Next: Jenkins Contributor Awards - Nominations Extended

≪ Previous: Jenkins Contributor Awards - Nominations Open

$

0

0

Beginning with Jenkins 2.335 and Jenkins 2.332.1, the Jenkins project is migrating from System V init(8) to systemd(1) in its official Debian, Red Hat, and openSUSE packages. The official Docker image and Helm chart remain unchanged. For up-to-date information, refer to the Managing systemd services page in the documentation.

Background

Beginning in 2008, the Jenkins (then Hudson) project has delivered Linux OS installation packages for Debian (and derivatives), Red Hat (and derivatives), and openSUSE. These packages were all based on the System V init(8) system in common use at that time. A remnant of the venerable Unix System V from 1983, init(8) had remained unchanged for decades.

The mid-2000s saw the emergence of a new generation of service management frameworks, starting with the release of Service Management Facility (SMF) in Solaris 10, the release of launchd in Mac OS X Tiger, and the release of Upstart in Ubuntu 6.10 (Edgy Eft). In contrast to the serial service startup of init(8), these frameworks modeled services as a dependency graph and started services in parallel.

The mid-2010s saw the rise of systemd(1) as the dominant service management framework on Linux, and it became the default service management framework in Red Hat Enterprise Linux (RHEL) 7, openSUSE 12.2 (Mantis), Debian 8 (Jessie), and Ubuntu 15.04 (Vivid Vervet). A decade after the release of Solaris 10, the ideas behind its service management framework had spread to the majority of Unix-like systems.

systemd(1) provides compatibility with the behavior exposed by System V init(8), and the System V init(8) scripts delivered in the Jenkins project’s official Linux OS packages continued to work in this compatibility mode. Beginning with Jenkins 2.335 and Jenkins 2.332.1, the Jenkins project’s official Linux OS packages deliver a native systemd(1)service unit, which supersedes the older System V init(8) scripts. Seven years after systemd(1) became the default service management framework in the majority of Linux distributions, the Jenkins project provides full support for systemd(1).

Motivation

As defined in W. Richard Stevens' book UNIX Network Programming (Addison-Wesley, 1990), a daemon is "a process that executes 'in the background' (i.e., without an associated terminal or login shell) either waiting for some event to occur, or waiting to perform some specified task on a periodic basis." Upon startup, a typical daemon program will:

• Close all open file descriptors, including standard input, standard output, and standard error

• Change its working directory to the root filesystem, to ensure that it does not tie up another filesystem and prevent it from being unmounted

• Reset its file mode creation mask (i.e., umask(2)) value

• Run in the background (i.e., call fork(2))

• Disassociate from its process group (usually a shell), to insulate itself from signals (such as SIGHUP) sent to the process group

• Ignore all terminal I/O signals

• Disassociate from the controlling terminal (and take steps not to reacquire one)

• Handle any SIGCLD signals

Most programs that are designed to be run as daemons do this work for themselves at startup, and Jenkins has traditionally done this using the Akuma daemonization library and Java Native Access (JNA). The Akuma library is no longer actively maintained, and recent versions of Java have placed increasingly greater restrictions on the ability of Java programs to access internal system state via reflection and other mechanisms. Furthermore, third-party daemonization software like daemonize(1) is not consistently packaged for all Linux distributions, and the packages that exist are frequently unmaintained or have bugs that cause regressions for Jenkins users. In other words, the status quo was increasingly unsustainable.

Users have also been requesting systemd(1) support in JENKINS-41218 since January 2017.

The migration to systemd(1) eliminates this long-standing pain point by relying on systemd(1) to daemonize the Jenkins Java process. This avoids the need for JNA-based tricks in Java, and it also unifies our implementation of service management across all Linux distributions. Furthermore, it allows for tighter integration between Jenkins core and the service management framework with regard to service startup notification.

Changes

Although systemd(1) has been the default service management framework in the majority of Linux distributions for seven years, some members of our community may not be familiar with its use in the context of managing Jenkins. The following section describes some of the changes in more detail and explains how to perform common system administration tasks. For up-to-date information, refer to the Managing systemd services page in the documentation. See also the DigitalOcean community systemd(1) tutorial to better understand the benefits of systemd(1) and the systemctl(1) command.

Package configuration

Users who run Jenkins 2.335 or later and 2.332.1 LTS or later through the official Debian, Red Hat, or openSUSE packages are affected by this migration.

The official Docker image and Helm chart remain unchanged.

The System V init(8) packages delivered the following configuration files:

Debian

/etc/default/jenkins

Red Hat

/etc/sysconfig/jenkins

openSUSE

/etc/sysconfig/jenkins

Each configuration file used a unique format, with the Debian version being radically different from the Red Hat and openSUSE versions. Furthermore, manual edits to these files would frequently conflict with updated upstream versions, triggering the package manager to flag the conflict and requiring manual intervention on upgrade.

New versions of Jenkins still ship these files and support Linux distributions that do not use systemd(1). At the time, no actively-supported distributions based on Red Hat or openSUSE are known to use System V init(8). On such systems, the /etc/sysconfig/jenkins file is left in place but unused at runtime. However, the Debian package can still be installed on distributions such as Devuan GNU+Linux, which is a fork of Debian without systemd(1). On such systems, the /etc/default/jenkins file will still be used at runtime.

When installed on a modern Linux distribution running systemd(1), the systemd(1)service unit is delivered to:

Debian

/lib/systemd/system/jenkins.service

Red Hat

/usr/lib/systemd/system/jenkins.service

openSUSE

/usr/lib/systemd/system/jenkins.service

The main service unit is read-only and not intended to be edited manually. It contains a large notice at the top of the file stating as much. The canonical way to customize the systemd(1) service is to run systemctl edit jenkins, which creates a new drop-in unit at /etc/systemd/system/jenkins.service.d/override.conf. On a clean install, this drop-in unit does not exist. When a user first customizes a clean install with systemctl edit jenkins, systemd(1) creates the drop-in unit and allows the user to customize it. Note that such customizations must be done in a [Service] section in order to take effect.

systemctl edit jenkins creates the drop-in unit as root with 0644 (-rw-r—​r--) permissions. The migration logic, on the other hand, creates the drop-in unit as root with 0600 (-rw-------) permissions. This might be of consequence if you store an HTTPS keystore location and/or password in the drop-in unit and also run jobs directly on the controller, a practice which the Jenkins project explicitly discourages. When in doubt, secure the drop-in unit by setting its permissions to 0600 with chmod(1).

One benefit of the drop-in unit is that it unifies configuration across all three distributions: Debian, Red Hat, and openSUSE. Gone are the days of maintaining distribution-specific configuration logic.

Also note that the drop-in unit is not overwritten on upgrades. Gone are the days of getting conflicts in /etc/{default,sysconfig}/jenkins on upgrades, at least after the upgrade to a systemd(1)-based package is completed.

Unlike the System V init(8) configuration, the override.conf file only contains customizations, not the original defaults. Users who are accustomed to editing an existing set of defaults must refer to the (read-only) service unit side-by-side when editing the drop-in unit or use a command like systemctl edit jenkins --full, which copies the original service unit instead of creating a drop-in unit.

Editing the drop-in unit with systemctl edit jenkins will automatically reload the systemd(1) configuration. The settings will take effect the next time Jenkins is restarted. If you edit the drop-in unit without systemctl(1), you need to run systemctl daemon-reload for the changes to take effect.

A final point to mention about the service unit is its use of specifiers, which may be unfamiliar to some users. The drop-in unit does not perform shell expansion. Specifiers can insert contextual information (like system hostname, unit name, and operating system kernel release) into the drop-in unit. The systemd(1) documentation contains a table of specifiers available in unit files.

Migration

The Jenkins project ships logic to automatically migrate the System V init(8) configuration file to the new systemd(1)override.conf format. This migration logic does nothing if an override.conf file already exists, which would be an indication that the migration script already ran or that the user has made their own customizations that should be preserved. If override.conf does not exist, package installation migrates the old System V init(8) configuration file to override.conf.

Logging

The systemd(1) package also uses systemd-journald(8) for logging by default. Rather than creating a log file in /var/log/jenkins/jenkins.log, Jenkins now logs to the system’s journal. Log entries may be viewed with journalctl -u jenkins. This is perhaps the most noticeable user-visible change in this migration.

See the DigitalOcean log management tutorial for more detailed information.

Startup notifications

The System V init(8) logic was asynchronous; i.e., running /etc/init.d/jenkins start would return prior to the completion of Jenkins startup. The systemd(1) logic is synchronous; i.e., running systemctl start jenkins will block until Jenkins signals successful startup. This allows system administrators to write automation to programmatically deploy Jenkins using modern tools like Ansible.

Jenkins previously restarted itself after upgrading plugins or via the /restart or /safeRestart endpoints by calling exec(2). This was fragile and exposed users to a variety of bugs. The systemd(1) implementation allows the main process to exit normally before starting it again from scratch. In addition to eliminating a category of bugs, this also provides more visibility into service startup progress. Some examples are shown below.

From systemctl status jenkins after upgrading plugins:

$ systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/lib/systemd/system/jenkins.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/jenkins.service.d
             └─override.conf
     Active: active (running) […]
   Main PID: […] (java)
     Status: "Restart in 10 seconds"

As Jenkins is being brought down:

$ systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/lib/systemd/system/jenkins.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/jenkins.service.d
             └─override.conf
     Active: deactivating (stop-sigterm) since […]
   Main PID: […] (java)
     Status: "Stopping Jenkins"

As Jenkins is starting up:

$ systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/lib/systemd/system/jenkins.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/jenkins.service.d
             └─override.conf
     Active: activating (start) since […]
   Main PID: […] (java)

After successful startup:

$ systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/lib/systemd/system/jenkins.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/jenkins.service.d
             └─override.conf
     Active: active (running) since […]
   Main PID: […] (java)

If Jenkins does not signal startup completion within a configured time, the service will be considered failed and will be shut down again. As each initialization milestone (i.e., "Started initialization", "Listed all plugins", "Prepared all plugins", "Started all plugins", "Augmented all extensions", "System config loaded", "System config adapted", "Loaded all jobs", "Configuration for all jobs updated", and "Completed initialization") is attained, the timeout is extended by the value of the jenkins.model.Jenkins.extendTimeoutSeconds system property (by default, 15 seconds). The timeout can be configured with the TimeoutStartSec directive in the service unit.

Reporting issues

If you find a regression, please file a bug report in Jira. When reporting an issue, include the following information:

1. Use the core component.

2. Provide the name, version, and architecture of the Linux distribution you are using (e.g., Ubuntu 20.04.4 LTS x86_64).

3. Provide the contents of the old System V init(8) configuration in /etc/{default,sysconfig}/jenkins, sanitized as necessary.

4. Provide the contents of the systemd(1) drop-in unit in /etc/systemd/system/jenkins.service.d/override.conf, sanitized as necessary.

5. Provide steps to reproduce the issue from scratch on a minimal Jenkins installation; the scenario should fail when the steps are followed on Jenkins 2.335 or later and pass when the steps are followed on Jenkins 2.334 or earlier.

Conclusion

We expect to see a bit of disruption from these changes but hope that in the long run they will save time for core and plugin developers and lead to a more secure and stable tool. Please reach out on the developers' mailing list with any questions or suggestions.

Jenkins Contributor Awards - Nominations Extended

March 29, 2022, 11:42 am

≫ Next: Spring Framework RCE, CVE-2022-22965

≪ Previous: Linux installation packages migrated from System V init to systemd

$

0

0

Jenkins Contributor Awards for 2022 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 has been extended to April 11, 2022. Voting will open later in April.

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 2022 on June 7.

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.

Spring Framework RCE, CVE-2022-22965

March 31, 2022, 2:14 pm

≫ Next: She Code Africa Contributhon 2022!

≪ Previous: Jenkins Contributor Awards - Nominations Extended

$

0

0

A remote code execution vulnerability has been identified in the Spring Framework.

This vulnerability is identified as CVE-2022-22965.

Spring officially reacted early in an early announcement.

Spring4Shell in Jenkins Core and Plugins

The Jenkins security team has confirmed that the Spring vulnerability is not affecting Jenkins Core. There is no impact because we are using Stapler as a servlet, and neither Spring MVC nor Spring WebFlux.

An analysis was done on the plugins to determine whether some were using Spring in a dangerous way. No impact was found.

The dangerous library is included as a dependency of spring-security-web, which is not yet updated to include the fixed version. The presence of Spring Framework is not enough to make the application vulnerable.

Spring4Shell in the Jenkins Infrastructure

The Jenkins infrastructure and security teams have confirmed that the Spring vulnerability is not affecting any part of the Jenkins infrastructure.

The following applications are Java applications that mention Spring as a dependency:

• The web service customize.jenkins.io was stopped out of an abundance of caution.

• The API of the web service plugins.jenkins.io is not affected, as it runs with JDK 8 and only GlassFish servlets.

• The web service accounts.jenkins.io is not affected, as it also runs with the JDK 8 and uses Stapler as a servlet.

We may decide to disable some services if we discover other vulnerabilities. You can see the status of services on the status page at status.jenkins.io.

Further Updates

We may update this blog post, if there are any corrections to be made, and in that case we’ll clearly call those out at the top.

She Code Africa Contributhon 2022!

April 11, 2022, 8:42 am

≫ Next: CI/CD with Postman and Jenkins

≪ Previous: Spring Framework RCE, CVE-2022-22965

$

0

0

The She Code Africa Contributhon started April 5, 2022. The She Code Africa Contributhon is a boot camp where African women are paid to work with open source organizations on selected projects with dedicated mentors. This program aims to create a more diverse, inclusive, and innovative culture within the African open source ecosystem by matching African women in technology with sponsor and mentor open source organizations. The 7 mentees joining the Jenkins project come from Nigeria, Kenya, and Ghana.

The Jenkins project has been accepted as a Contributhon mentoring organization. We’re spreading the project work between three different project ideas and are being helped by a She Code Africa project manager. The projects include:

• Inclusive naming improvements

• Pipeline help improvements

• Screenshot updates

We’re in the community bonding phase, using the Contributhon Onboarding Guide to prepare for the projects.

We’d like to introduce our mentees so that you recognize them and can welcome them during code review and online chat.

Nafeesat Jimoh

Nafeesat is a Python programmer and a project manager based in Nigeria. She loves to collaborate and learn from others as well as share knowledge. She is the project manager for the Jenkins project in the She Code Africa Contributhon.

You’ll recognize her contributions as j-enny on GitHub.

Catherine Kiiru

Catherine is based in Nairobi, Kenya. She is a front-end developer, technical content specialist, and open source enthusiast. Having transitioned from marketing to tech, Catherine is passionate about building exciting software solutions and using technical content to communicate their value to end users. She has been assigned to the inclusive naming project.

You’ll recognize her contributions as CatherineKiiru on GitHub.

Peace Okafor

Peace is based in Nigeria. She is a technical writer with knowledge of writing code. She has worked as a freelancer for 4 years and counting. She has been assigned to the inclusive naming project. She is happy to be a part of the She Code Africa Contributhon.

You’ll recognize her contributions as Ladyprowess on GitHub.

Afi Gbadago

Afi is based in Ghana. She has been assigned to the Pipeline help project.

You’ll recognize her contributions as AfiMaameDufie on GitHub.

Sophia Okito

Sophia Okito is based in Nigeria. She is a Java Backend Developer at Quabbly. She has been assigned to the Pipeline help project. She loves to try new things and is glad to be working on her first open source project.

You’ll recognize her contributions as Sophia-Okito on GitHub.

Somaa Chukwu

Somaa Chukwu is based in Nigeria. She is a full stack developer. She loves working with teams and is super excited for the opportunity to participate in the Jenkins project. She has been assigned to the screenshot updates project. Looking forward to an amazing experience and working with everyone.

You’ll recognize her contributions as somaathetechster on GitHub.

Miracle Ugorji

Miracle Ugorji is based in Nigeria. She is a frontend developer and technical writer. She is an open-source enthusiast. She’s glad for this opportunity to kick start her open-source journey. She has been assigned to the screenshot updates project.

You’ll recognize her contributions as amarealcoder on GitHub.

About the projects

The projects this year are:

• Inclusive naming - use correct terms like "controller" and "agent" in online help, documentation, and messages

• Pipeline help - improve online help and documentation of Jenkins Pipeline steps

• Screenshot updates - identify and update version specific screenshots in Jenkins documentation

More information about She Code Africa and the Contributhon is available from the Contributhon description and the She Code Africa site .

Conversations related to the Contributhon are happening in a Continuous Delivery Foundation slack channel.

Mentors

We’re very grateful to the mentors from the Jenkins project that are hosting mentoring sessions, reviewing pull requests, and encouraging the mentees. Thanks to:

• Angélique Jard

• Kevin Martens

• Kristin Whetstone

• Mark Waite

We also thank Zainab Abubakar of She Code Africa for her efforts to facilitate the Contributhon and encourage participation.

CI/CD with Postman and Jenkins

May 2, 2022, 10:42 am

≫ Next: DigitalOcean sponsors the Jenkins project

≪ Previous: She Code Africa Contributhon 2022!

$

0

0

The Postman API Platform is redefining how APIs are built, managed, and consumed. An important aspect of API management is continuous building, testing, and deployment with CI/CD tools. With the latest release of Postman, we bring the API builds closer to your API by integrating with Jenkins.

Observe your Jenkins builds

While you iterate over your APIs, the Jenkins builds are triggered multiple times. While some of you may be looking at builds closely in Jenkins, not everyone in your team has access to the Jenkins instance. Team members often depend upon other means such as emails and slack messages to get informed of the recent builds and their status. With the Jenkins Integration, the build information can now be seen within Postman under the Test tab of the API.

This allows you to actively monitor your API builds along with the other components of the API. You can also trigger a build from Postman itself, allowing you to quickly test any changes in the API.

Get automation test reports from anywhere in Postman

Newman is a CLI tool that is used to run the collections outside Postman. Teams use it to run their tests in CI/ CD pipelines, test environments, etc. While you could pull tests from Postman using APIs to run via Newman, the test reports had to be consumed outside Postman. This creates multiple sources for you to refer to while checking the automation test status of your APIs.

With the latest release, you now get the reports of automation tests running anywhere in Postman. The Newman reporter posts the results as a collection run in the History. The results can also be seen combined with your build reports from the CI/CD, giving you a single place to analyze your builds and associated tests.

A version of this post appeared on the Postman Blog.

DigitalOcean sponsors the Jenkins project

May 4, 2022, 2:12 pm

≫ Next: Enforced HTTPS for 'mirrors.jenkins.io' and consolidation of the Jenkins Mirrors

≪ Previous: CI/CD with Postman and Jenkins

$

0

0

The Jenkins infrastructure team has extended the reach of the ci.jenkins.io agents. We’re grateful that DigitalOcean has donated $2760 to the Jenkins project. The donation has allowed us to run jobs from ci.jenkins.io on an additional cluster hosted by DigitalOcean.

Easy setup

We defined a new Kubernetes cluster on DigitalOcean with the DigitalOcean Terraform provider. The infrastructure is defined as code in our DigitalOcean infrastructure repository.

Resource management

The DigitalOcean user interface makes it easy to see our progress applying the DigitalOcean donation to continuous integration jobs for the Jenkins project.

We track our budget and our droplets from easy to use web pages that are part of the DigitalOcean platform.

Automated cluster upgrades

The DigitalOcean managed Kubernetes cluster provides automated upgrades. Upgrades happen weekly and keep the infrastructure current with the latest capabilities.

Smooth autoscaling

We’ve seen smooth and effective resource allocation and deallocation on DigitalOcean as the load increases and decreases.

DigitalOcean tutorials for Jenkins

Step by step DigitalOcean installation instructions are available from the "How to install Jenkins" tutorials on the DigitalOcean community site.

---

Enforced HTTPS for 'mirrors.jenkins.io' and consolidation of the Jenkins Mirrors

May 13, 2022, 12:42 pm

≫ Next: Welcome Google Summer of Code 2022 Contributors!

≪ Previous: DigitalOcean sponsors the Jenkins project

$

0

0

The Jenkins project provides a download mirror infrastructure allowing to download Jenkins packages and plugins from a download server close to your location.

How Does it Work?

When a download request is emitted to either mirrors.jenkins.io or get.jenkins.io, an HTTP redirect response to a mirror download server is answered.

The Jenkins infrastructure uses a database of existing mirror servers provided by volunteers and donators to select the closest mirror to your location: this is currently the role of the distinct mirrors.jenkins.io and get.jenkins.io services.

Consolidation

The system behind mirrors.jenkins.io is using a software named "mirrorbrain" and was originally used by the Jenkins infrastructure to provide download redirections to mirrors.

A new system was introduced in 2020: get.jenkins.io, using "mirrorbits" which is a great fit for a Kubernetes environment (lightweight, horizontally scalable) and provides a set of nice WebUI features to see the mirror list and grading.

INFO: Try it by yourself, check the mirrors providing the latest Jenkins LTS distribution: https://get.jenkins.io/war-stable/2.332.3/jenkins.war?mirrorlist

It’s been 2 years and the new system is clearly the most reliable: that’s why we, the Jenkins Infrastructure team, want to retire the "mirrorbrain" system.

In consequence, the 19th of May 2022, the domain name mirrors.jenkins.io will be changed to point to the actual "mirrorbits" system already available at get.jenkins.io.

This consolidation ensures all users downloading a Jenkins package or a plugin will use the closest download mirror to their location, without having to maintain 2 distinct systems.

Enforced HTTPS

The main consequence is that the HTTPS protocol will be enforced for the request to the domain mirrors.jenkins.io.

The "mirrorbrain" system currently serving requests behind the domain mirrors.jenkins.io is not available through HTTPS, which is a safety issue for users downloading files.

The 19th of May 2022, that won’t be the case anymore: like get.jenkins.io, HTTPS will be available and enforced for the requests going through the domain mirrors.jenkins.io.

What Does It Change for Me?

• Short answer: nothing. You should already be using the domain get.jenkins.io as it’s been the default since almost 2 years, and the content served by both system is the same.

• Long answer: if you are still using the former mirrors.jenkins.io and are not able to switch to get.jenkins.io, you’ll see the following changes:

• 🌍 The mirror usually selected might change as the grading system on mirrorbits is different (and covers way more mirrors): faster downloads for you!

• 🔐 Your HTTP requests will be redirected to their corresponding URL using the HTTPS protocol with a valid TLS certificate signed by the Let’s Encrypt authority: improved safety!

• ⚠️ The IP pointed by the DNS record mirrors.jenkins.io will change from 52.202.51.185 to 52.167.253.43: upgrade your proxies!

Welcome Google Summer of Code 2022 Contributors!

May 20, 2022, 1:43 pm

≫ Next: Docker Image: new Exit and Restart Behavior for Controllers

≪ Previous: Enforced HTTPS for 'mirrors.jenkins.io' and consolidation of the Jenkins Mirrors

$

0

0

On behalf of the Jenkins GSoC team and mentors, We would like to welcomeDheeraj Singh Jodha,Yiming Gong,Hrushikesh Rao, andVihaan Thora. They will be working on Google Summer of Code projects in the Jenkins organization, and they have already done some contributions.

This year we have the following projects:

• Plugin Health Scoring System - Provide a 'plugin health indicator' for plugin maintainers and Jenkins administrators.

  • Contributor: Dheeraj Singh Jodha from India

  • Mentors: Jake Leon, Adrien Lecharpentier, and Aditya Srivastava

• Jenkinsfile Runner Action for GitHub Actions - Implement a (near) feature-complete version of Jenkinsfile Runner Action for GitHub Actions.

  • Contributor: Yiming Gong from Carnegie Mellon University, USA

  • Mentors: Kris Stern, Abhyudaya Sharma, and Shubham Kumar

• Automatic git cache maintenance on the controller - Automate the maintenance of cached git repositories on the Jenkins controller.

  • Contributor: Hrushikesh Rao from Jawaharlal Nehru Technological University, India

  • Mentors: Mark Waite and Rishabh Budhouliya

• Pipeline Step Documentation Generator Improvements - "Enhance the Jenkins Pipeline documentation generator to produce better documentation for thousands of Pipeline developers".

  • Contributor: Vihaan Thora from Indian Institute of Technology, Indore, India

  • Mentors: Kristin Whetstone, Harshit Chopra, andTasneem Koushar

During the next weeks project teams will be reaching out to potential stakeholders in order to establish connections and to get comments regarding their project designs. If you are interested in the projects, please join discussions in theDeveloper mailing lists and project meetings once they get scheduled. Please also expect expect more detailed blogposts about the projects soon.

If you are interested to know more about GSoC in Jenkins, you can find information, timeline and communication channelshere.

Docker Image: new Exit and Restart Behavior for Controllers

May 27, 2022, 1:43 pm

≫ Next: Let the (GSoC) coding start !

≪ Previous: Welcome Google Summer of Code 2022 Contributors!

$

0

0

The Jenkins project provides Docker images for controllers (and more). Beginning with Jenkins 2.344 released April 18, 2022 and Jenkins 2.332.3 released May 04, 2022, the behavior of the "Exit" and "Restart" lifecycle of the controller image jenkins/jenkins changed.

TL;DR; Ensure that you have a Container Restart Policy For quick readers: check the How to Add a Container Restart Policy section for immediate actions to be taken.

Application Lifecycle in a Container World

Jenkins previously restarted itself after upgrading plugins or via the /restart or /safeRestart endpoints by calling exec(2). This was fragile and exposed users to a variety of bugs.

The ExitLifecycle implementation allows the main process to exit normally before starting it again from scratch, relying on the exit code to signal to the container orchestrator that the container ought to be restarted rather than to remain shut down.

Avoiding exec(2) from Java code, with all the associated complexity of closing file handles and making low-level system calls via JNA, eliminates exposure to a category of bugs.

You can read more about this on the following issues: jenkinsci/jenkins#5899 and jenkinsci/docker#1268.

Delegate Restarts to the Container Engine

Since the Jenkins Weekly 2.344 and the Jenkins LTS 2.332.3, the Docker image for Jenkins controller uses the new lifecycle ExitLifecycle by default.

It means that when the Jenkins controller triggers any "restart" or "exit" event, then its container exits.

If you are running Jenkins in a controller as a container, you should add a "container restart policy" different than none to ensure that the container is restarted automatically.

If you are running Jenkins in production in a container, chances are great that you already have a restart policy set and the change will be transparent. But we updated the jenkinsci/docker documentation to mention that the flag --restart=on-failure is set when starting a Jenkins controller container.

How to Add a Container Restart Policy

If you do not have a container restart policy defined, please find the different following methods depending on your container orchestrator:

• Docker Engine, Docker Swarm: add the flag --restart=on-failure to the docker run <…​> jenkins/jenkins command.

  No need to create a new container: you can use the command docker update to update the restart policy of an existing container.

• Docker Compose: update your docker-compose.yml file to specify the restart: on-failure keyword (or the deploy.restart_policy if using docker compose deploy to a Docker Swarm cluster)

• Kubernetes:

  • If you are using the official Jenkins helm-chart, make sure that you are using at least the version 3.10.3 of the Helm chart and you’re good to go, as per jenkinsci/helm-charts#529

  • Otherwise, ensure that you configure the Deployment for Jenkins to specify the OnFailure restart policy for the pods. Please note that it’s the default policy if unspecified.

• Hashicorp’s Nomad: Ensure that you specify a non-empty restart stanza. Please note that the default stanza behavior behaves as expected: Jenkins is restarted.

Let the (GSoC) coding start !

June 13, 2022, 3:12 pm

≫ Next: SVG icon migration (breaking changes!)

≪ Previous: Docker Image: new Exit and Restart Behavior for Controllers

$

0

0

The GSoC community bonding period just finished.

The four Jenkins GSoC projects are now ready. Contact between contributors and mentors is established. Regular communication channels are setup (weekly project meetings and dedicated chat). Links to the project plans and plannings drafts are published on the project pages.

Next step, the actual coding!

Together with their mentors, Dheeraj, Ymming, Hrushikesh, and Vihaan will work the whole summer on their respective projects.

End July, we will perform a public progress review. During an online meetup, the GSoC contributors will present their project. They will be invited to share what has been done to date. And why not, make a first preliminary demo. This is an opportunity for the community to comment, advise and become more involved with the project.

SVG icon migration (breaking changes!)

June 20, 2022, 4:13 pm

≫ Next: Jenkins requires Java 11

≪ Previous: Let the (GSoC) coding start !

$

0

0

Summary

Beginning with Jenkins v2.333 (released on June 15, 2022), Jenkins core has upgraded from GIF and PNG icons to SVG icons. Plugins that will be affected by this change are tracked in a spreadsheet found in JENKINS-68251. Plugins that do not interact with icons are unaffected by this change.

Background

Scalable vector graphics (SVG) icons provide a more attractive user interface. They are able to adapt to themes like the dark theme and the solarized theme. The SVG icons provide a more consistent experience for users. SVG images also preserve image quality, ensuring that icons are displayed properly regardless of scale.

Many plugins have been updated to use the new icons. A tracking spreadsheet lists plugins that have been reviewed for possible issues.JENKINS-68251 is the Jenkins issue that tracks the change. It contains a link to the tracking spreadsheet.

Make sure that you update all plugins before and after updating to Jenkins 2.333 or later.

Reporting issues

In the spreadsheet, there is a table labeled “Abandoned plugin, to be discussed”.

The table contains plugins that have had no SCM activity for at least 5 years.

When reviewing this table, if the list includes plugins that you are using, please contact the plugin maintainer to request an update to the plugin. Many plugins already have a pull request submitted. The pull request needs to be tested, merged, and released. You can help the maintainer by testing the pull request and reporting the results of your testing.

If the maintainer has abandoned the plugin, please consider adopting the plugin yourself. After adoption, use the icon path to icon class migration instructions to update the plugin.

When reporting SVG icon migration issues, please provide the following information:

1. Use the ‘svg-migration’ label

2. Provide configuration details as described in "How to report an issue", including Jenkins core version and the name and version of all installed plugins

3. Include a screenshot of the issue

Conclusion

While many of the commonly used plugins have already been updated for SVG icon usage, there are unmaintained plugins that could cause errors or breakages. If you are in a situation where a plugin has been abandoned, adoption is the only way to ensure that there are no disruptions during usage.

Jenkins requires Java 11

July 1, 2022, 9:12 am

≫ Next: Jenkins Contributor Summit at DevOps World 2022 - Call for Participation

≪ Previous: SVG icon migration (breaking changes!)

$

0

0

Introduction

The Jenkins project is committed to delivering a world-class platform experience for end users and developers alike. At the core of this experience is Java, an object-oriented programming language with a cross-platform runtime in the form of the Java virtual machine (JVM). Since its inception, the Jenkins project has been a major consumer of Java, distributing over 1,800 plugins to an installed base of over 300,000 controllers, and Jenkins regularly appears on lists of the top Java applications of all time.

Beginning with Jenkins 2.357 (released on June 28, 2022) and the forthcoming September LTS release, Jenkins requires Java 11. Additionally, beginning with Jenkins 2.355 (released on June 14, 2022) and Jenkins 2.346.1 LTS (released on June 22, 2022), Jenkins supports Java 17. Plugins have already been prepared in JENKINS-68446.Use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.357.

Long-time Jenkins users and Java developers may recall previous migrations to Java 7 and Java 8. While these migrations were not trivial, they pale in comparison to the magnitude of the migration to Java 9 and beyond. Java 9 represents a sea change in the Java ecosystem across many dimensions. Not only are there changes to licensing policies, versioning schemes, release cadences, and long-term support (LTS) cycles, but also there are a number of significant technical changes to the language and runtime (e.g., Project Jigsaw), not all of them retaining the high levels of compatibility that characterized previous releases. Although these evolutionary changes are likely to be in the best interests of the Java community in the long term, it is nevertheless incumbent on the community to be aware of the impact and to plan accordingly.

In this blog post, we will discuss the Jenkins project’s migration to Java 11 and Java 17, reflecting on it in the context of previous Java migrations within the Jenkins project and the Java community more broadly. We will summarize the benefits and risks and describe the upgrade process. Finally, we will share a glimpse at what is coming in future releases.

History

Since its inception in 2005, the Jenkins (then Hudson) project has gone through a number of Java migrations. To a large degree, the present migration is consistent with historical precedent within the Jenkins project. For years the Jenkins project has published anonymous usage statistics, as described in a piece by R. Tyler Croy and recently revised by Andrew Bayer, which enable us to quantify past and present trends.

Data

Analysis

The above data reveals that the lifecycle of each major Java version is clearly a Gaussian function. Each major version of Java is released by the vendor, begins a phase of rapidly growing adoption, reaches a usage peak, loses support from the Jenkins project, begins a decline in usage, declines in usage to a terminal state, and finally reaches vendor end-of-life (EOL), in roughly that order.

Extrapolating further, one can observe the following trends:

• It takes at least a year for Jenkins users to begin to adopt a new release of Java.

• Once Jenkins users begin to adopt a new version of Java, usage of the preceding Java version eventually reaches a peak and begins to decline.

• The Jenkins project has historically started requiring a new Java version roughly halfway through the period of decline of the preceding Java version.

• Once Jenkins requires a given Java version, usage of the preceding Java version continues to decline until it reaches a terminal stage of decline.

• The abovementioned terminal stage of decline typically correlates with the end of active support from the Java vendor.

Conclusion

Critically, the Jenkins project has never required a given version of Java until the preceding version is clearly declining in usage. This reduces risk by ensuring that the majority of users are successfully running the new version in production. Conversely, the requirement of a new Java version for Jenkins users incentivizes the remaining users to upgrade and prevents users who are reluctant to upgrade from putting the project at risk by continuing to rely on a version that is reaching vendor end-of-life (EOL).

The requirement for Java 11 is consistent with historical precedent. Usage of Java 8 peaked in February 2021 and has been declining since then. Meanwhile, adoption of Java 11 has been increasing rapidly since November 2019 but has not yet reached a peak. The time is right to require Java 11.

A new era for Java

The release of Java 9 heralded a new era in the evolution of the Java Platform. In addition to new features (e.g., Project Jigsaw), it introduced a new versioning scheme and release cadence. Originally, there was a new major version released every few years. After Java 9, the release schedule changed to a new major version every six (6) months, with a Long Term Support (LTS) release of Java selected every few major versions.

Java 8, Forever & Always?

Members of the Jenkins community, spearheaded by Oleg Nenashev, began working on Java 11 support in 2018. At the time, Java 9, 10, and 11 had not yet achieved significant levels of adoption. In a piece on LinkedIn’s journey to Java 11, Jesse Jie provides the following anecdote:

As an anecdote, some sessions at the Oracle Code One conference in late 2019 asked attendees if their products were using Java 9 or higher to which only about 20% of the room said that they were; few major companies had adopted Java 11 either.

— Jesse Jie

These observations match our own experience in the Jenkins project. Many users are choosing to stay on Java 8, and Java vendors are responding in turn by extending support for Java 8: to May 2026 (in the case of Adoptium, Amazon Corretto, and IBM Semeru) and to December 2030 (in the case of Azul and Oracle). This is an unprecedented level of support for a version of Java originally released in 2014.

While the Jenkins project could remain on Java 8 for the foreseeable future, this would be imprudent for several reasons. First, many key third-party libraries consumed by the Jenkins project (e.g., Jetty, JGit, Spring Framework, and Spring Security) are beginning to require newer versions of Java, and staying on Java 8 puts the Jenkins project at risk of eventually not being able to receive security updates from upstream projects.

Furthermore, significant runtime improvements have been made to the Java Platform in recent years. For example, LinkedIn saw drastic performance improvements when migrating to Java 11, and Adoptium saw significant memory usage improvements when migrating to Java 11 (on Jenkins, no less!). Recent Java runtimes provide a number of improvements to garbage collection, among other areas.

Finally, Jenkins takes pride in its strong development community, and staying on a current version of Java helps attract and retain developers. As one developer put it in a 2015 mailing list post:

In the context of recruiting (OSS) developers, I think Java moves slowly enough (especially cf. C#) to damage its mindshare without additionally making it all less fun by making everyone act like a corporate IT developer stuck on an obsolete platform. That just drives people to work on CI systems that don’t have that constraint.

— Nigel Magnay

Trouble with JAXB

Prior to Java 11, Java Architecture for XML Binding (JAXB) was part of the Java Platform, and one could use it without adding a third-party dependency. Beginning with Java 11, JAXB is no longer a part of the Java Platform and requires adding a third-party dependency. Thanks to work done several years ago by Baptiste Mathus and others, a JAXB Jenkins plugin is available, which provides the JAXB library to Jenkins plugins in the form of a plugin-to-plugin dependency.

The vast majority of plugins have already been prepared to support Java 11 via the JAXB plugin in JENKINS-68446. Jenkins users need only upgrade plugins to compatible versions as documented in the Released As field in Jira.It is critical to use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.357. Failure to upgrade plugins to compatible versions may result in ClassNotFoundException, NoClassDefFoundError, or other low-level Java errors.

Dr. OpenJDK or: How I Learned to Stop Worrying and Love Java 9 and Beyond

The world of Java development was shaken in 2019 when Oracle changed the licensing policy for Java 8. Recent years have seen the proliferation of a number of different Java vendors:

• Adoptium (then AdoptOpenJDK)

• Amazon Corretto

• Azul Platform Core (then Zulu)

• BellSoft Liberica JDK

• IBM Semeru

• Microsoft OpenJDK

• Oracle Java

• Red Hat OpenJDK

Yes, even Microsoft now has a build of OpenJDK.

The presence of so many options can be initially daunting. In recent years, the Jenkins project has been using and recommending Adoptium/Eclipse Temurin, which is the Java vendor used in the official Jenkins Docker images and the Java vendor used to power the Jenkins project’s infrastructure. Reciprocally, we are also pleased to note that Adoptium builds are done with Jenkins.

Java 11 vs. Java 17

At the center of the vast majority of the abovementioned Java distributions is the OpenJDK project, which brings us to our final point. Throughout the development of this project, we repeatedly encountered issues that were resolved in Java 17 but not yet backported to Java 11. As good citizens of the open source community, we contributed backports where applicable for the benefit of Jenkins users and the broader Java community.

Java 17 support in Jenkins is brand new, and it has not yet reached a stage of rapid adoption within the Jenkins community. Nevertheless, our experience has been that Java 17 is usually a more reliable choice than Java 11. We enthusiastically invite the Jenkins community to begin adopting Java 17, and we can say with confidence that the migration from Java 11 to Java 17 will not be nearly as painful as the migration from Java 8 to Java 11.

Upgrading to Java 11 or 17

Docker images

The official Jenkins Docker images have been based on Java 11 for many months, with Java 8 available as a fallback and Java 17 available in preview mode. Beginning with Jenkins 2.357, the Java 8 images will be retired and the Java 17 images will transition from preview to general availability (GA). Users of the official Jenkins Docker images need not install or configure Java on their own, as it comes preinstalled in the image.

OS packages

Users of the official Jenkins OS packages for Debian, Red Hat, and SUSE Linux distributions should note that these packages are agnostic to the Java vendor. In other words, you must bring your own Java package. One straightforward way to do this is to install Java 11 from your Linux distribution, as described on the package download site:

Debian

apt-get install fontconfig openjdk-11-jre

Red Hat

yum install fontconfig java-11-openjdk

openSUSE

zypper install dejavu-fonts fontconfig java-11-openjdk

By virtue of not requiring any custom repositories, this is certainly the simplest method (and the one used by the Jenkins project’s packaging tests), but it does not give the user a high degree of control over the Java runtime environment. As mentioned previously, the official Jenkins Docker images use Adoptium/Eclipse Temurin (as does the Jenkins infrastructure project). Enthusiastic users may wish to install Java from Adoptium or another vendor. Adoptium recently began providing Linux installation packages, as described in a piece by George Adams. Ultimately, the choice of which Java vendor to use is your own, as long as that vendor provides Java 11 or Java 17. Refer to your chosen Java vendor for installation instructions.

Once you have installed a suitable version of Java, configure Jenkins to use that Java runtime. The most straightforward way is to configure that version of Java as the default version of Java at the operating system (OS) level:

Debian

update-alternatives --config java

Red Hat

alternatives --config java

openSUSE

update-alternatives --config java

Alternatively, users who do not wish to change the default version of Java can customize the JAVA_HOME or JENKINS_JAVA_CMD environment variable as part of the Jenkins systemd(1) service unit. Refer to the Managing systemd services section of the Jenkins documentation for more information.

Garbage collection options

Users who have customized Java garbage collection options should note that these options have changed in recent versions of Java. Refer to the following CloudBees Support article for the recommended garbage collection options for Java 11:

-XX:+AlwaysPreTouch
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=${PATH}
-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:+ParallelRefProcEnabled
-XX:+DisableExplicitGC
-XX:+UnlockDiagnosticVMOptions
-XX:+UnlockExperimentalVMOptions
-Xlog:gc*=info,gc+heap=debug,gc+ref*=debug,gc+ergo*=trace,gc+age*=trace:file=${PATH}/gc.log:utctime,pid,level,tags:filecount=2,filesize=100M
-XX:ErrorFile=${PATH}/hs_err_%p.log
-XX:+LogVMOutput
-XX:LogFile=${PATH}/jvm.log

	Java 6	Java 7	Java 8	Java 11
Vendor release date	December 11, 2006	July 7, 2011	March 18, 2014	September 25, 2018
Rapid adoption	October 2009 (11,193 installations)	February 2013 (10,997 installations)	February 2015 (12,210 installations)	November 2019 (10,094 installations)
Peak usage	March 2013 (47,244 installations)	June 2015 (68,681 installations)	February 2021 (261,468 installations)	N/A
Jenkins weeklies require next major version	May 2015 (21,798 installations)	April 2017 (40,569 installations)	June 2022 (185,286 installations)	N/A
Terminal decline in usage	May 2016 (10,283 installations)	March 2019 (10,123 installations)	N/A	N/A
Vendor End of Life (EOL)	December 31, 2015	July 31, 2019	At least November 2026	At least October 2024

These options are explained in-depth in the Oracle Java documentation as well as the CloudBees Jenkins JVM guide.

Agents

For best results, it is recommended to run agents with the same version of Java as the version used on the controller. Use the Versions Node Monitors plugin to verify that agents are running a compatible version of Java.

Running the Jenkins remoting process on an agent with Java 11 or 17 does not imply that you need to run your builds with the same version of Java. You can continue to use any desired version of Java for individual builds.

Reporting issues

If you find a regression in a plugin, please file a bug report in Jira:

• JENKINS-67688: Java 11 Phase 5: Require Java 11 or newer

When reporting an issue, include the following information:

1. Use the JENKINS-67688 epic.

2. Provide the output of java -version (e.g., OpenJDK 64-Bit Server VM build 11.0.15+10-Ubuntu-0ubuntu0.22.04.1)

3. Provide the name, version, and architecture of the operating system you are using (e.g., Ubuntu 20.04.4 LTS x86_64).

4. Provide the complete list of installed plugins as suggested in the bug reporting guidelines.

5. Provide the complete stack trace, if relevant.

6. Provide steps to reproduce the issue from scratch on a minimal Jenkins installation; the scenario should fail on Jenkins 2.356 or earlier when the steps are followed on Java 11 or Java 17 and pass when the steps are followed on Java 8.

Future work

We expect to see usage of Java 11 continue to grow until it reaches a peak. We expect to see usage of Java 8 continue to decline until it reaches a terminal state, as was the case for Java 7 and Java 6. We expect to see usage of Java 17 transition from minimal levels to significant levels. To reach our goal of Java 17 as the recommended Java version, we need cooperation from both Jenkins users and contributors alike. The development work for Java 17 support is tracked in the following Jira epics:

• JENKINS-67908: Java 17 Phase 1: Support Java 17

• JENKINS-67909: Java 17 Phase 2: Deprecate support for Java 11

• JENKINS-67907: Java 17 Phase 3: Require Java 17 or newer

If you have made it this far through this post, you are clearly enthusiastic about the Jenkins platform experience. If you have never contributed, why not? We would love to work with you. Join one of our Platform Special Interest Group (SIG) meetings to learn more.

Conclusion

We expect to see a bit of disruption from these changes but hope that in the long term they will be in the best interests of the Jenkins community. Please reach out on the developers' list with any questions or suggestions.

Acknowledgments

As noted above, members of the Jenkins community began working on Java 11 support in 2018, well before the present author’s involvement in the project and well beyond the present author’s ability to identify and name everyone who was involved in the effort. In addition to the many plugin maintainers who merged and released JAXB fixes in a timely fashion, we would like to thank the following regular contributors for their recent efforts:

• Adrien Lecharpentier

• Alexander Brandes

• Alex Earl

• Andrew Bayer

• Baptiste Mathus

• Carroll Chiou

• Damien Duportal

• Daniel Beck

• Devin Nusbaum

• Dr. Ullrich Hafner

• Jesse Glick

• Kevin Martens

• Mark Waite

• Oleg Nenashev

• Olivier Lamy

• Tim Jacomb

• Vincent Latombe

Thank you! It would not have been possible without you.