We are happy to announce that the Jenkins community has moved all its official IRC channels to Libera chat. We have started our migration on May 26 as a response to the hostile takeover of hundreds of open source community channel by the new Freenode management. As decided by the Jenkins governance meeting on June 16th, Libera Chat IRC channels are the only official channels going forward. A more detailed history of the transition is available on the Jenkins developers mailing list. What did we move? We have created the following IRC chats: that currently live on freenode to libera.chat: #jenkins - general discussion channel for Jenkins users and developers. We no longer consider it a central chat for all things Jenkins, but we intend to keep it available to users who want to keep using IRC. #jenkins-hosting - Chat used by the Hosting Team to manage hosting automation #jenkins-infra - Chat used by the Infrastructure Team to coordinate efforts related to Jenkins project infrastructure and the incident response #jenkins-release - Chat used for Jenkins core release coordination by the Release Team All other channels have NOT been moved to Libera Chat IRC and were replaced by other channels. Most notable channels: #jenkins-meeting - the Jenkins Governance Meeting uses combination of Zoom and Google Docs at the moment. We do not longer use the IRC chat for that purpose. #jenkins-cert - no private chat going forward. The Security Team will use mailing lists only going forward #jenkins-community - Replaced by the Advocacy&Outreach Gitter channel. Freenode concerns and disclaimers Going forward, the Jenkins community does not have ANY official channels on Freenode. All channels are either removed or left abandoned. We no longer manage or control our channels. Most of the Jenkins IRC channel operators use IRCCloud, and hence they were banned by the Freenode team on June 11th. Only a few operators have reconnected since this event. Taking the takeover of Freenode and hostile actions taken by the new management, we can no longer guarantee any of the following: Authenticity of registered users on Freenode. All IRC accounts, cloaked or not, might have been taken over by the new Freenode management. Do not trust messages from the Jenkins contributor account IDs there. Confidentiality of private channels like #jenkins-cert. We performed audit of the conversations there, and we believe there are no undisclosed security vulnerabilities referenced in the channel. After all, this IRC has been rather dormant for the last 18 months. IRC User Passwords. All passwords on Freenode IRC may be compromised in the future. We strongly advise all users to rotate their passwords if they were used on Freenode IRC. We have made backups of IRC channel conversations in the abandoned channels. If you need to access the conversation history, please reach out to the Jenkins Infrastructure team. Acknowledgements We thank the entire Libera Chat team and all contributors who have worked on creating a Freenode replacement for hundreds of open source communities using IRC. Within just a month, a new platform has been created and adopted by almost all active projects. We remember the Hudson to Jenkins renaming days when a similar mobilization happened in the Jenkins community, and we appreciate all the effort put by contributors. Special thanks to Tim Jacomb, Gavin Mogan, Alex Earl, and Olivier Vernin for their work on the migration of IRC channels and our automation like the IRC Bot used by the Jenkins hosting team. What’s next? In the Jenkins community we will keep using Libera Chat IRC and maintaining user and contributor channels there. Other Jenkins chat channels like Gitter and Slack are unchanged. We intend to gradually replace many of those channels with community.jenkins.io. This is a new portal powered by Discourse. The service is sponsored by Civilized Discourse Construction Kit, Inc.. It is currently in preview, stay tuned for announcements. As always, we will appreciate any suggestions and feedback!

The She Code Africa Contributhon started April 1, 2021. 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 5 mentees joining the Jenkins project come from Nigeria, Kenya, and Rwanda. The Jenkins project has been accepted as a Contributhon mentoring organization. Our project idea will introduce mentees to Jenkins and plugin development as they create Pipeline examples and create Pipeline help for Jenkins Pipeline plugins. Twice weekly mentoring sessions are scheduled with the mentees and are listed in the events calendar. We’ve already received the first pull request to improve the embedded documentation that generates the Steps Reference and provides contextual help in the Snippet Generator. We’re looking forward to more pull requests and more improvements throughout April, 2021. We’d like to introduce our mentees so that you recognize them and can welcome them during code review and online chat. Onyinye Ezike Onyinye is based in Lagos, Nigeria. She’s a junior fullstack software developer who is very passionate about learning. She uses Angular, React, Nodejs, and Spring Boot. She has spent the last two years building up herself in software development and she’s hoping to become a world-class software developer. You’ll recognize her contributions as Onyimatics on GitHub and on the Jenkins issue tracker. Sharon Jebitok Sharon is based in Kenya. She’s a software development student at Microverse, a remote school for software developers. She has been an active member of She Code Africa and she’s presently a mentee on She Code Africa’s Contributhon Program with the Jenkins project. She has spent one year in the software industry since she switched her career into tech, learning to write meaningful code and collaborate with other developers/designers and the tech community. You’ll recognize her contributions as jebitok-dev on GitHub and as jebitok16_ on the Jenkins issue tracker. Esther Ejidike Esther is a frontend developer based in Lagos, Nigeria. She is one of the participants in the She Code Africa Contributhon Open Source Program working with Jenkins and will be contributing to the nodes and processes plugin. She loves to convert designs to exact replicas in the form of webpages and she likes to learn new things in her free time. You’ll recognize her contributions as Queen-esther01 on GitHub and as esther101 on the Jenkins issue tracker. Cynthia Iradukunda Cynthia Iradukunda is based in Kigali, Rwanda. She is currently a junior Computing student at the African Leadership University (ALU) in Mauritius. She wants to be a software engineer because it will help her solve real-world problems while also allowing her to use her coding skills. Her coding skills include but not limited to Java, JavaScript, and attention to detail. By contributing to the Git plugin, she hopes to help users have a smooth process using its documentation, get involved with the project, and connect with other community members. You’ll recognize her contributions as ciradu2204 on GitHub and as ciradu2204 on the Jenkins issue tracker. Lucy Karimi Lucy is based in Nairobi, Kenya. She is a software developer with experience in mobile app development. She is very passionate about tech and is currently involved in the SheCodeAfrica Contributhon. You’ll recognize her contributions as luciahroyalty101 on GitHub and as luciahroyalty101 on the Jenkins issue tracker. About the Contributhon projects See the previous blog post for more information about She Code Africa, the Contributhon, and the plans for Jenkins. Jenkins development tasks She Code Africa Contributhon mentoring organizations She Code Africa Contributhon She Code Africa 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: Meg McRoberts Mark Waite Kristin Whetstone Oleg Nenashev Angélique Jard We also thank Zainab Abubakar of She Code Africa for her efforts to facilitate the Contributhon and encourage participation.

She Code Africa is a non-profit organization focused on celebrating and empowering young girls and women in technology across Africa. They provide resources and events that help women grow and achieve their personal and career goals. Their mentoring programs provide help and guidance as participants learn and grow in their careers. This year, She Code Africa is organizing the She Code Africa Contributhon. 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. Jenkins in She Code Africa Contributhon The Jenkins project has been accepted as a Contributhon mentoring organization. Our project idea will introduce participants to Jenkins and plugin development as they create Pipeline examples and create Pipeline help for Jenkins Pipeline plugins. Participants will learn more about Jenkins Pipeline and will submit plugin pull requests with examples and online help. The Jenkins Pipeline Steps Reference and Pipeline online help often receive feedback that more examples are needed, that step return values need to be described, and that arguments need more description of their purpose, allowed values, and expected results. Most plugin maintainers do not provide detailed documentation of the pipeline steps, or the arguments to those pipeline steps. This project will improve the documentation of pipeline steps and their arguments while introducing Jenkins Pipeline, Jenkins plugin development, Jenkins documentation as code, and the concepts of GitHub forks and pull requests. We’ve identified development tasks that up to three Contributhon participants will complete during April. The tasks will introduce the participants to Jenkins plugin development. They will experiment with plugin changes in Jenkins and submit pull requests to provide Pipeline examples and help. They will meet twice a week with Jenkins mentors, Kristin Whetstone, Mark Waite, and Meg McRoberts to review their progress, provide coaching, and help with issues. Data driven choices We’ve been collecting Jenkins documentation feedback since 2017. Now we’re using that feedback to prioritize the plugins to improve as part of this project. The top 10 Pipeline plugins that have received the most feedback are: Build step SCM step Git step Input step Nodes and processes steps Workspace cleanup step Basic Pipeline steps Slack notification steps HTTP request step Email extension steps What about my plugin? If you are a plugin maintainer and would like help to add examples and online help for the Pipeline steps in your plugin, send email to the Jenkins Documentation mailing list. We’ll consider including additional plugins as we better understand the development pace for She Code Africa participants.

The Jenkins Contributor Summit brings together current and future contributors to the Jenkins project. We’re hosting an online summit this year to encourage contributors from around the world to meet, discuss, and plan for the future. The Contributor Summit will be Tuesday, February 23rd 2021 through Thursday, February 25, 2021. The summit brings together community members to learn, meet, and help shape the future of Jenkins. In the Jenkins community we value all types and sizes of contributions and love to welcome new participants. Format The online format allows greater flexibility for meeting times and topics. Contributors will meet to discuss specific topics in smaller groups at times that are convenient for those in the meeting. Opening session The opening session will start Tuesday, February 23, 2021 at 15:00 UTC. After an initial welcome and overview, we’ll hear from leaders in the Jenkins project as they share the results from the previous 12 months and outline ideas for the next 12 months. Security - Daniel Beck Infrastructure - Olivier Vernin Release - Tim Jacomb User experience - Félix Queiruga Chinese localization - 赵晓杰(Rick) Configuration as code - Tim Jacomb Google Summer of Code - Kara de la Marck Documentation - Mark Waite Events and Advocacy - Alyssa Tong Cloud Native - Kara de la Marck Platforms - Mark Waite After those presentations, we’ll create "breakout rooms" in the online meeting that will allow those interested in specific tracks to meet, identify preferred times for their tracks, and prepare draft agendas for their tracks. Tracks Smaller sessions ("tracks") will be run in the 48 hour period between the opening session and the closing session. These smaller sessions will be focused on specific topics. A track leader will organize the track meeting, facilitate discussions in the track meeting, and present a summary of the track results in the closing session. Closing session The opening session will start Thursday, February 25, 2021 at 15:00 UTC. After an initial welcome and overview, we’ll hear from track leaders as they share the results from their track meetings. We’ll identify items that should be added to the Jenkins roadmap, items that should be further investigated by special interest groups, and items that need further discussion elsewhere.

Beginning with Jenkins 2.279 and Jenkins 2.263.4, the Jenkins project is upgrading the base operating system and Java version used in the jenkins/jenkins:latest and jenkins/jenkins:lts images. The update replaces OpenJDK 8u242 with AdoptOpenJDK 8u282 and replaces Debian 9 ("Stretch") with Debian 10 ("Buster"). Why? We’re changing the base image so that we have a better supported operating system and a more current Java release for Jenkins controllers. Better supported operating system The Docker images provided by the Jenkins project rely on the operating system security processes of the operating system provider. Our Docker images have used Debian 9 ("Stretch") for multiple years. Debian 9 security updates have been discontinued as of July 6, 2020. Debian 9 Long Term Support security updates will be discontinued at the end of June 2022. The upgrade to Debian 10 keeps us on an operating system maintained by the operating system security team. More current Java release The Debian 9 Docker images were based on the openjdk:8-jdk-stretch Docker image. The last update to that image was one year ago with the release of JDK 8u242. We need a maintained Docker base image that keeps pace with JDK releases and operating system updates so that the controller is running the most recent Java updates and most recent operating system updates. Other Jenkins controller images have already switched from using openjdk base images to instead use base images provided by Eclipse Adoptium. Eclipse Adoptium is the Eclipse project formed when AdoptOpenJDK joined the Eclipse Foundation. This change adapts the jenkins/jenkins:latest and jenkins/jenkins:lts images to use the Adoptium JDK images in the same pattern as is already used for the Jenkins JDK 11 Docker images like jenkins/jenkins:lts-jdk11. The Jenkins Platform SIG has enjoyed very good results in our interactions with the Eclipse Adoptium project. We look forward to continuing our collaboration with them. Thanks a lot to Alex Earl and Jim Crowley for the image build restructuring groundwork that made the image upgrade possible! Also thanks to Oleg Nenashev and other contributors for their reviews and testing. Packaging changes The Jenkins Docker image based on Debian 10 ("Buster") includes some different packages than Debian 9 ("Stretch"). Some packages have been removed because they are no longer supported by their communities. Some packages have been removed due to infrequent and decreasing use. Users of the Jenkins Docker images may need to extend their definition of their Docker image to include packages that are no longer included in the base image. SCM packages removed The following source control management packages are no longer included in the Jenkins controller images for jenkins/jenkins:latest or for jenkins/jenkins:lts : bzr mercurial subversion Other packages removed Additional packages that are no longer included in the Jenkins controller images include: bzip2 mime-support python (the Python project stopped supporting Python 2 January 1, 2020) xz-utils A detailed list of the exact package changes is available in the pull request. Upgrade and compatibility notes The Jenkins controller images are designed to be extended to meet user needs. Custom Jenkins controller images can be created from the base images and are designed to allow additional Jenkins plugins and additional operating system packages. For example, the Installing Docker instructions illustrate a technique to install the Blue Ocean plugins and some operating system packages in a custom Docker image. Docker image with Subversion The following Docker image definition installs the most recent Jenkins Long Term Support release with the subversion plugin and the operating system subversion command: FROM jenkins/jenkins:lts USER root RUN apt-get update && \ apt-get install -y --no-install-recommends subversion USER jenkins RUN jenkins-plugin-cli --plugins subversion:2.14.0 Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-subversion:1.1": docker build -t myjenkins-subversion:1.1 . Docker image with Mercurial The following Docker image definition installs the most recent Jenkins Weekly release with the mercurial plugin and the operating system hg command: FROM jenkins/jenkins:latest USER root RUN apt-get update && \ apt-get install -y --no-install-recommends mercurial USER jenkins RUN jenkins-plugin-cli --plugins mercurial:2.12 Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-mercurial:1.1": docker build -t myjenkins-mercurial:1.1 . What’s next? We will continue Docker image updates as new Java versions are released. If you are interested in new features in Jenkins Docker packaging, stay tuned for future announcements! There are multiple ongoing initiatives which you can find on the public Jenkins roadmap. Some stories: Switching to AdoptOpenJDK. General availability of Windows images. Support for more platforms (AArch64, IBM s390x, PowerPC). Introducing multi-platform Docker images. If you are interested in any of these projects and would like to contribute, please reach out to the Platform Special Interest Group which coordinates initiatives related to Jenkins in Docker.

The Jenkins project has used Jira to track issues for many years. Jenkins core, Jenkins modules, Jenkins infrastructure, and many Jenkins plugins manage their issue reports with our Jira server. Jira helps the Jenkins project manage issues and tasks related to over 250 000 Jenkins installations. It tracks bugs, enhancement requests, tasks, and security issues. It is used regularly by users around the world. We’re grateful for the long-standing contribution that Atlassian provides by donating the Jira license to the Jenkins project. We’re grateful to the Oregon State University Open Source Lab for their donation of equipment and bandwidth to host the server. Upgrade Timeline We were running Jira 7.13 and had been managing that installation for a few years. Atlassian announced that Jira 7.13 would end its support life on November 28, 2020. We needed to upgrade from Jira 7.13 to a more recent version of Jira. As part of our membership in the Continuous Delivery Foundation, a Linux Foundation initiative, we could use their project services team to manage our Jira server. We decided to move from hosting our own Jira server to having the Jira experts at the Linux Foundation host it. The upgrade timeline looked like this: November 2019 - Infrastructure team begins discussions about the November 2020 end of support for Jira 7.13 August 2020 - First conversations with Linux Foundation to host Jira for the Jenkins project. Draft of the upgrade plan assembled and shared with the community September 2020 - Schedule for testing week and final transition week proposed. Authentication options evaluated and selected October 2020 - Test upgrade performed and tested November 2020 - Final upgrade completed and verified Confronting the Complications Initial discussions between the Jenkins infrastructure team and the Linux Foundation identified complications related to authentication and SSL certificates. We planned, negotiated, and tested our assumptions throughout the project. Authentication Jira servers at the Linux Foundation typically use Linux Foundation accounts for user access. Unfortunately, the Jenkins LDAP database includes over 100,000 users and for many of them, Linux Foundation username doesn’t correspond to Jenkins account username. It was not feasible to transition 100,000 user accounts from the Jenkins LDAP database to the Linux Foundation accounts system and still complete the Jira upgrade before the November 28, 2020 deadline. The Linux Foundation Project Services team evaluated authentication alternatives and confirmed that they could use the Jenkins LDAP server. Using the Jenkins LDAP server spared us from two transitions, LDAP and Jira, and kept the project timeline feasible. SSL Certificates Jira servers at the Linux Foundation use Let’s Encrypt to generate SSL certificates for HTTPS. The Linux Foundation uses the DNS method to obtain SSL certificates. Unfortunately, the Jenkins project uses the HTTP method to obtain SSL certificates. Thankfully, Olivier Vernin of the Jenkins project and Anton Baranov of the Linux Foundation found a solution. They created an ACME record in the Jenkins DNS server and pointed the issues.jenkins.io DNS record at the new Linux Foundation Jira server. Building the Prototype Anton Baranov created a prototype Jira server, restored an older Jenkins Jira backup, and upgraded it to Jira 8.13. That first restore detected that we had not provided the Jira attachments or the Jira avatars. That attachments and avatars added multiple gigabytes to the initial backup data and were vital to complete the update. Testing the Upgrade A group of volunteers including Jenkins users, security team members, and infrastructure team members tested the upgrade during the week of October 26, 2020. The tests confirmed that authentication worked as expected and that the Jira prototype was functioning as expected. We thank the test team, including: Daniel Beck Tim Jacomb Olivier Vernin Mark Waite The tests included: Creating and routing issues Commenting on issues Viewing dashboards with the expected content LDAP settings Email notification The tests detected minor issues that Anton was able to correct in preparation for the final upgrade. The testing team agreed that the tests were successful. Deploying the Upgrade Olivier Vernin announced the final upgrade by email to the Jenkins infra list with details of the changes happening during the upgrade. Monday, November 9, 2020, the final backup of the existing Jira server was copied into the new Linux Foundation server. The final upgrade encountered issues that we had not seen during the initial tests. The "bumps and bruises" from the unexpected issues were resolved by Anton Baranov as he used a multi-step upgrade process. The steps included: Restore the earlier backup to Jira 7.13 Restore the most recent backup Upgrade to Jira 8.13 Install avatars, attachments, and other images Update DNS entries to point to the new Jenkins Jira server Lessons from the Upgrade Lessons were related to timing, estimation, and communication. Scheduling the Upgrade The test upgrade started the week of October 19, 2020. It took several days longer than originally expected. Thankfully, we had allowed an extra week between the test upgrade and the production upgrade. The originally announced schedule for the final upgrade was intentionally placed in a week that would not include a long term support release. That reduced the risk of disruption if the upgrade took longer than required or failed and we had to roll back. Estimating the Work Discussions with the Jenkins project Jira administrators and the Linux Foundation Jira experts provided very reasonable estimates of time to complete the work. We intentionally allowed additional time between first test and final upgrade. We needed that additional time and used it well as the testing week. Communicating the Plan The distributed nature of the Jenkins project makes communication challenging for major changes. We communicated plans at various stages but still found occasions where the communication was insufficient. In this case, the adage held true that it is, "impossible to communicate too much". Thanks for your patience during the upgrade and thanks to the Linux Foundation for administering the Jenkins Jira server.

Recently we have selected Jenkins 2.263 as a new baseline for the LTS release line, with ETA in December 2020. It allows delivering significant and in some cases breaking changes which have been previously on hold. Beginning with the Jenkins 2.264 release on October 27, 2020, we’ve entered a period where the Jenkins weekly releases will include more significant changes than usual. That period of more significant changes is expected to continue for a month or more. As you may have seen from the release community ratings, there might be regressions and instabilities during this period. We’re excited for the changes. They help to improve user experience and to address the technical debt accumulated in the Jenkins core. We invite Jenkins users to evaluate those changes and provide feedback. This is an especially valuable time for users and administrators to test the weekly releases and report issues with them, especially on Jenkins test environments. In the Jenkins project we have invested a lot in test coverage for the main functionality, but in many cases we rely on user feedback for exotic plugins and environments not yet covered by our test automation. The most notable changes include: Configuration UI - Tables to Divs Core - Spring Security replaces Acegi Security Core - XStream unfork UI - JQuery upgrade Configuration UI - Tables to Divs Jenkins 2.264 is the first weekly release to include the "Tables to Divs migration" user interface work of Josh Soref, Tim Jacomb, and Felix Queiruga. It is a significant step to improve forms in the Jenkins user interface (configuration pages, build parameters, etc.), especially for users on narrow devices like tablets and phones. A better user interface The transition from using HTML table tags to using HTML div tags provides a more attractive user interface for all users and a much better experience for users on narrower devices. Before the conversion from table tags to div tags, the"Manage Jenkins" page looked like this in a 1024x768 window: After the conversion, the"Manage Jenkins" page now looks like this: The user interface improvements from the transition are a nice step forward for Jenkins. However, because the user interface improvements require changes in plugins, we need your help. We need users to test the latest weekly Jenkins releases with the plugins and configurations that are most important to them. When users detect an issue, we need them to report the issue with enough detail that a plugin maintainer can fix the issue. Please add the tables-to-divs-regression label to the issues. The tables-to-divs-regression label makes it easier to find issues related to the tables to divs transition. Plugin developers Several plugins have already been identified that may need changes. See the Jira epic for plugins that are likely to need changes for the new user interface layout. The list of open tables-to-divs-regression issues can also be used to see plugins that need changes. If you can assist with plugin testing and code changes, select one of the plugins from that epic, test it, and propose a pull request to help with this user interface transition. If you’re not comfortable proposing a pull request, describe the problems you see in a bug report. A tables to divs migration guide is available. It describes areas that typically need to be changed as part of the migration from tables to divs. It also includes detailed examples that allow the plugin to continue supporting older Jenkins versions with table layouts and use div layouts for newer Jenkins versions. Core - Spring Security replaces Acegi Security The Jenkins 2.266 release on November 10, 2020 will include the migration to the Spring Security libraries from the Acegi security libraries that Jesse Glick has proposed and developed through jep:227[Jenkins Enhancement Proposal 227]. This upgrade replaces the Acegi Security library with the current release of the Spring Security library. Details of the change are described in jep:227[] and in the pull request. We need users to test the latest Jenkins weekly releases with their plugins and watch for issues related to authentication. Refer to Jesse Glick’s blog post that introduces the details of the change and provides links to the Spring Security compatibility table. Jesse’s blog post provides specific instructions for those who report bugs related to this change. Please use those instructions as you submit bug reports related to the Spring Security upgrade. Core - XStream unfork Jenkins has been using a fork of the XStream serialization library to read and write XML files. The XStream library was forked over 10 years ago and had a few fixes applied to it. Unfortunately, at that time the fixes were rejected by the upstream maintainers of XStream (unsupported patterns of API use) and the fork fell behind the upstream version. The Jenkins 2.266 release on November 10, 2020 will include the migration to the upstream version of the XStream library that Jesse Glick has proposed and developed through jep:228[Jenkins Enhancement Proposal 228]. Refer to Jesse Glick’s blog post that introduces the details of the change and provides links to the XStream compatibility table. Jesse’s blog post provides specific instructions for those who report bugs related to this change. Please use those instructions as you submit bug reports related to the XStream upgrade. UI - JQuery upgrade Jenkins uses a 1.x version of the jQuery user interface library for some of its components. Felix Queiruga has started the work to update that library to a current jQuery version. It will arrive in a future Jenkins weekly release. When it arrives, it will be noted in the Jenkins weekly changelog. When the jQuery update arrives, We will need users to test the Jenkins weekly release with the plugins and configurations that are most important to them. When users detect an issue, we need them to report the issue with enough detail that a plugin maintainer can fix the issue. Call to test This is a great time to help the Jenkins project by testing the weekly releases. We encourage you to test the user interface and the interactions that are most important to you. If you find an issue, please report the issue so that others can benefit from your discovery.

This article describes our observations during Windows testing of the Jenkins 2.249.1 release candidate. Upgrade testing Jenkins 2.249.1 is a new long term support release with user interface improvements and changes in Windows support. It is the first long term support release to drop support for Microsoft.NET framework 2.0. The end of support for Microsoft.NET framework 2.0 was announced in the Windows Support Updates blog post. The Windows support upgrade guidelines describe major things to consider when upgrading Jenkins controllers and agents on Windows. As part of our preparation for the release, we tested several configurations. This article describes our experiences with those configurations. Upgrade approaches We tested controller and agent upgrades from Jenkins 2.235.x to 2.249.1-rc on Windows. The tests included: 32 bit Windows MSI 64 bit Windows MSI WAR (file) on Windows Upgrade process Our upgrade process included: Install a previous version of Jenkins controller on Windows Install a previous version of Jenkins agent on Windows and configure it as a service Upgrade Jenkins controller from "Manage Jenkins" Restart the Jenkins Windows service for the controller Upgrade the Jenkins agent on Windows with the latest agent.jar Restart the Jenkins Windows service for the agent Testing results We successfully tested Restarting Windows service for controller ( JENKINS-63198) Restarting Windows service for agents ( JENKINS-63223) We confirmed that we can continue our Level 1 support policy for Jenkins 2.249.1. 32 bit Windows MSI Prior to Jenkins 2.235.3, the Jenkins LTS Windows installer was provided as a 32 bit MSI and included a bundled Java 8 runtime environment. The Jenkins agent can be downloaded and run through Java web start using the bundled Java 8 runtime environment. The agent can also be configured to run as a service using the bundled Java 8 runtime environment. Jenkins controller Jenkins 2.235.1 installs JRE 8u144 for 32 bit Windows. The installer configures the Jenkins controller to run as the SYSTEM user. Refer to the Windows Installer Updates blog post for details of the controller installation process with the 32 bit MSI. Jenkins agent Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port. Configure the agent Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Download the agent The agent starts the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser. Start the agent The downloaded file needs to be opened from a command prompt using the javaws command that is included with the bundled JRE: C:\> "C:\Program Files (x86)\Jenkins\jre\bin\javaws.exe" -wait slave-agent.jnlp The javaws program has been removed from the most recent releases of Java 8 and from Java 11. Refer to [Jenkins agent and icedtea] for a technique that can help users of the most recent releases of Java 8. Java web start (javaws.exe) prompts for permission to run the program with this dialog: Install the agent as a service The agent runs and displays a window on the desktop with a single menu entry, "Install as a service". When the "Install as a service" menu item is clicked, the agent is adjusted to run as a Windows service using the SYSTEM account. Upgrade the controller The Jenkins controller on Windows can be upgraded to Jenkins 2.249.1 from the "Manage Jenkins" page. The upgrade process downloads the new jenkins.war file, saves the current version in case of later downgrade, and offers to restart. Upgrade the agent The Jenkins inbound agent is not upgraded automatically. The agent administrator downloads the most recent agent.jar from their Jenkins controller, stops the running agent, and replaces the installed agent.jar with the downloaded version. The agent service will reconnect to the Jenkins controller after the administrator restarts it. 64 bit Windows MSI Beginning with Jenkins 2.235.3, the Jenkins LTS Windows installer is a 64 bit MSI. It runs Jenkins with the 64 bit JDK (Java 8 or Java 11) selected by the user. Jenkins controller Jenkins 2.235.3 was installed using AdoptOpenJDK Java 8u262 in one test. It was installed using AdoptOpenJDK Java 11.0.8 in another test. In both cases, the installer configured the Jenkins controller to run with the Windows service account we had previously configured. Refer to the Windows Installer Updates blog post for details of the controller installation process with the 64 bit MSI. Jenkins agent Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port. Configure the agent Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Once the Jenkins TCP port is open for inbound agents, a new agent is configured from the Jenkins "Nodes" menu This creates an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Download the agent The agent was started the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser. Start the agent with IcedTea-Web Recent versions of Java 8 and all versions of Java 11 have removed the javaws command. Jenkins agents for Java 8 can still be started with the javaws command, but it needs to be downloaded separately from the JVM. We open "slave-agent.jnlp" from a command prompt using the javaws command that is available from AdoptOpenJDK IcedTea : C:\> C:\icedtea-web-1.8.3.win.bin\icedtea-web-image\bin\javaws.exe -wait slave-agent.jnlp Java web start (javaws.exe) prompts for permission to run the program with this dialog: Install the agent as a service The agent runs and displays a window on the desktop with a single menu entry, "Install as a service". When the "Install as a service" menu item is clicked, the agent is installed and configured to run as a Windows service using the SYSTEM account. Upgrading the controller The Jenkins controller on Windows was upgraded to Jenkins 2.249.1 from the "Manage Jenkins" page. The upgrade process downloads the new jenkins.war file, saves the current version in case of later downgrade, and offers to restart. Upgrading the agent The Jenkins inbound agent is not upgraded automatically or from a Jenkins user interface. The agent administrator downloads the most recent agent.jar from their Jenkins controller and replaces the installed agent.jar with the downloaded version. WAR (file) on Windows Jenkins allows users to run the Jenkins web archive (WAR) file from a command line and then install it as a service from within Jenkins. This installation technique uses the Jenkins WAR file but does not use a Windows MSI package. The Jenkins WAR file includes the necessary components to install and configure Jenkins as a service. Install controller as a service When the Jenkins war file is started from a Windows command prompt, "Manage Jenkins" includes "Install as a service". An administrator selects that entry and Jenkins will configure itself to run as a service/ The installer configures the Jenkins controller to run as the SYSTEM user. Jenkins agent Jenkins agents on Windows are often configured to "Launch agent by connecting it to the master". The Jenkins agent configuration correctly warns that the controller must open the TCP port for inbound agents in the "Configure Global Security" page. It is easiest to allow Jenkins to choose the port (a "Random" port). Jenkins selects a random available port number and shares that port number with agents during their initial connection to the Jenkins http port. Configure the agent After opening the Jenkins TCP port for inbound agents, we configured a new agent from the "Nodes" menu This created an "inbound Jenkins agent" that uses the Jenkins agent.jar to initiate the connection to the Jenkins controller. Download the agent The agent was started the first time by clicking the "Launch" button on the agent configuration page (only available with Java 8). That downloads the "slave-agent.jnlp" file from the web browser. Start the agent with IcedTea-Web Recent versions of Java 8 and all versions of Java 11 have removed the javaws command. Jenkins agents for Java 8 can still be started with the javaws command, but it needs to be downloaded separately from the JVM. Open "slave-agent.jnlp" from a command prompt using the javaws command that is available from AdoptOpenJDK IcedTea-Web : C:\> C:\icedtea-web-1.8.3.win.bin\icedtea-web-image\bin\javaws.exe -wait slave-agent.jnlp Java web start (javaws.exe) prompts for permission to run the program with this dialog: Install the agent as a service The agent runs and displays a window on the desktop with a single menu entry, "Install as a service". When the "Install as a service" menu item is clicked, the agent is installed and configured to run as a Windows service using the SYSTEM account. Conclusion Jenkins controller installation is best done with the new 64 bit MSI package. Previous controller installations can be upgraded to the most recent Jenkins release from within Jenkins. Jenkins inbound agent installation is more complicated now that the javaws.exe program is not included in the JDK. The AdoptOpenJDK IcedTea-Web project allows administrators to install and configure Jenkins inbound agents with most of the ease that was available in prior Java releases.