Recent Blog Posts

This event is over, thanks a lot to all contributors! Please the event page for results. On behalf of the Jenkins User Experience, Documentation and Advocacy and Outreach special interest groups, we are happy to announce the online UI/UX hackfest on May 25-29! Everyone is welcome to participate, regardless of their Jenkins development experience. The goal is to get together and work on improving Jenkins user experience, including but not limited to user interface and user documentation. We also invite you to share experiences about Jenkins and to participate in UX testing. The event follows the Jenkins is the Way theme and the most active contributors will get special edition swag and prizes! Event plan This hackfest is NOT a hackathon. We do not expect participants to dedicate all their time during the event timeframe, but hop-in/hop-out as their time allows. Everybody can spend as much time as they are willing to dedicate. Spending a few days or just a few hours is fine, any contributions matter regardless of their size. Jenkins development experience is not required, we have newcomer-friendly stories for those who want to start contributing to the project. We will also have a 24/7 jenkinsci/hackfest Gitter chat for Q&A and coordination between contributors. There will be 3 main tracks : User Interface - Improve look&feel and accessibility for Jenkins users, work on new read-only interface for instances managed with configuration as code, create and update Jenkins themes, and many other topics. This track is coordinated by the UX SIG. User Documentation - Improve and create new user documentation, tutorials and solution pages. Also, there is ongoing documentation migration from Wiki to jenkins.io and plugin repositories. This track is coordinated by the Documentation SIG. Spread the word - Write user stories for Jenkins Is The Way site and the Jenkins blog, post about your Jenkins user experience and new features, record overview and HOWTO videos, etc. This track is coordinated by the Advocacy and Outreach SIG. We are working on publishing project ideas and issues for the listed tracks. The current list can be found on the UI / UX hackfest event page, this list will be finalized by the beginning of the hackfest. You are welcome to propose your own projects within the User Experience theme. During the event, we will organize online meetups and ad-hoc training sessions in different timezones. All these sessions will be recorded and shared on our YouTube channel. There are no mandatory sessions you must attend, you are welcome to join ones remotely or watch the recordings. After the event we will invite participants to demo their projects at online meetings or recorded sessions. Registration This event is over, thanks a lot to all contributors! P.S: Note that the registration form has a question top 3 things we could change in Jenkins to improve your user experience. We would appreciate your response there! Contacts Please use the following contacts to contact organizers: Gitter chat Mailing list Resources Event Page Registration form. Project ideas (work-in-progress). The full list will be published by the beginning of the event. Frequently Asked Questions Contributing to Jenkins Code of Conduct Swag and Prizes Thanks to our sponsors ( CloudBees, Inc. and Continuous Delivery Foundation), we are happy to offer swag to active contributors! 50 most-active contributors will get an exclusive "Jenkins Is The Way" T-shirt and stickers Active contributors will get Jenkins stickers and socks We are working on special prizes for top contributors, to be announced later Acknowledgements We thank all contributors who participate in this event as committers! We especially thank all reviewers, organizers and those who participated in the initial program reviews and provided invaluable feedback. In particular, we thank User Experience, Documentation and Advocacy and Outreach SIG members who heavily contributed to this event. We also thank sponsors of the event who make the swag and prizes possible: CloudBees, Inc. and Continuous Delivery Foundation (CDF). In addition to swag, CloudBees donates working time for event hosts and reviewers. CDF also sponsors our online meetup platform which we will be using for the event. .

We would like to announce the availability of official Windows agent images for Docker. These images allow provisioning Jenkins agents with Windows OS on Docker and Kubernetes. New images All official Docker images for agents now provide nanoserver-1809 and windowsservercore-1809 tags which include Windows images and, at the moment, Java 8 (these are like the latest tag). We also provide tags with explicit Java selection, e.g. jdk8-windowsservercore-1809 or jdk11-nanoserver-1809. Version tags are also available, e.g. jenkins/agent:4.3-4-jdk8-nanoserver-1809. jenkins/agent is a basic agent which bundles the agent.jar for agent ⇐ ⇒ controller communication. This is most useful as a base image for other images. Windows images are available starting from version 4.3-4 jenkins/inbound-agent is an agent that is based on the jenkins/agent image above. It provides a wrapper script written in PowerShell to help specify the parameters to agent.jar. Windows images are available starting from version 4.3-4 jenkins/ssh-agent is an image which has OpenSSH installed and should be used with the SSH Build Agents Plugin. Windows images are available starting from version 2.1.0 Using Windows Docker images To use the new images, you will need a proper Docker or Kubernetes environment which supports running Windows containers. For Windows desktop users, the easiest way is to use Docker for Windows. Windows support in Kubernetes is documented here. jenkins/agent The jenkins/agent image is a simple agent with the JDK and the agent.jar (Jenkins Remoting library). There are two main use cases for this image: As a base image for other Docker images (e.g., FROM jenkins/agent:jdk8-nanoserver-1809 in your Dockerfile). The jenkins/inbound-agent is based on this image. This image may also be used to launch an agent using the Launch method of Launch agent via execution of command on the master. This allows the controller to launch the agent inside the docker container automatically. To run the agent for the second use case, you would specify the following command on the Jenkins controller after setting Remote root directory to C:\Users\jenkins\agent : docker run -i --rm --name agent --init jenkins/agent:jdk8-windowsservercore-1809 java -jar C:/ProgramData/Jenkins/agent.jar jenkins/inbound-agent The inbound-agent Docker image tries to provide a higher level interaction with the agent.jar executable. It provides a PowerShell wrapper script around agent.jar and it is specified as the entrypoint so that you just need to pass in some command line arguments to run the agent. A pull request has been opened which documents these command line parameters and environment variables. Example: docker run jenkins/inbound-agent:windowsservercore-1809 ` -Url http://jenkins-server:port ` -WorkDir=C:/Users/jenkins/Agent ` -Secret ` -Name Example using environment variables: docker run -e "JENKINS_URL=http://jenkins-server:port" -e "JENKINS_AGENT_NAME=AGENTNAME" ` jenkins/inbound-agent:windowsservercore-1809 ` -WorkDir=C:/Users/jenkins/Agent ` -Secret ` -Name The -Url, -Name and -Secret parameters are required, but can be specified as either command line parameters or environment variables. jenkins/ssh-agent As mentioned above the jenkins/ssh-agent docker image is based on SSH communication with the controller, rather than the remoting TCP or WebSocket protocols. The image sets up a jenkins user and the OpenSSH server so that the controller can connect to the agent via SSH. The image expects an SSH public key as a parameter and puts that key into the authorized_keys file for the jenkins user. The private key should be specified in the agent configuration on the controller to allow the controller to connect. Example: docker run jenkins/ssh-agent:jdk8-windowsservercore-1809 "" You can also pass the public key as an environment variable when using docker run. Example: docker run -e "JENKINS_AGENT_SSH_PUBKEY=" jenkins/ssh-agent:jdk8-windowsservercore-1809 You will then be able to connect this agent using the SSH Build Agents Plugin as "jenkins" with the matching private key. What’s next? We are considering providing versions based on Windows Server 2019 build 1909 so that Jenkins users can run these images on GKE clusters (see this issue). We are also looking into providing multiarch manifests which would allow Windows images to be part of the latest tag. There is also an open pull-request to create a Windows based Docker image for a Jenkins controller. There hasn’t been a lot of requests for this, but to make the offerings complete for Windows users, the pull request was created. For plans unrelated to Windows, please see the Docker images for agents: New names and What’s next blogpost.

We would like to announce the renaming of the official Docker images for Jenkins agents. It does not have any immediate impact on Jenkins users, but they are expected to gradually upgrade their instances. This article provides information about the new official names, upgrade procedure, and the support policy for the old images. We will also talk about what’s next for the Docker packaging in Jenkins. New image names jenkins/agent is the new name of the old jenkins/slave image, starting from 4.3-2 jenkins/inbound-agent is the new name of the jenkins/jnlp-slave image, starting from 4.3-2 jenkins/ssh-agent is the new name of the old jenkins/ssh-slave image, starting from 2.0.0 See the upgrade guidelines below. Why? The "slave" term is widely considered inappropriate in open source communities. It has been officially deprecated in Jenkins 2.0 in 2016, but there are remaining usages in some Jenkins components. The jira:JENKINS-42816[Slave to Agent renaming leftovers] EPIC tracks cleanup of such usages. Official Docker agent images were a glaring case, it was not easy to fix that with the previous versions of the image release Pipelines on DockerHub. It is great to have the image naming issue finally fixed by this update. Another notable change is replacing the JNLP agent term with inbound agent. Historically "JNLP" has been used as a name of Remoting protocols. JNLP stands for Java Network Launch Protocol which is a part of the Java Web Start. Jenkins supports Java Web Start mode for agents when running agents on Java 1.8, but our networking protocols are based on TCP and have nothing to do with Java Network Launch Protocol. This name has been very confusing since the beginning and became worse with the introduction of WebSocket support in Jenkins 2.217 (jep:222[]). Docker agent images support WebSockets, so we decided to change the image name to jenkins/inbound-agent so that it prevents further confusion. Inbound agent term refers to agent protocols in which the agent initiates the connection to the Jenkins controller through different protocols. Thanks a lot to Alex Earl and krufab for the repository restructuring groundwork which made the renaming possible! Also thanks to Tim Jacomb, Marky Jackson, Mark Waite, Ivan Fernandez Calvo and other contributors for their reviews and testing. Upgrading and Compatibility Notes Good news, there are no breaking changes caused by this renaming. All images have been already modified to use the new terminology internally. If you use the recent versions of the previous images, you can just replace the old names with the new ones. These names may be referenced in your Dockerfiles, scripts, and Jenkins configurations. We will keep updating the old images on DockerHub for at least 3 months (until August 05, 2020). There will be no new configurations and platforms added to the old images, but all existing ones will remain available (Debian for Java 1.8 and 11, Alpine for Java 1.8, etc.). After August 05, 2020, the old images will no longer receive updates, but previous versions will remain available to users on DockerHub. What’s next? We will continue renaming of the Docker images in Jenkins components which reference old image names. There is also a set of convenience Docker images which include build tools like Maven or Gradle which will be renamed later. The jenkins/ssh-agent image might be renamed again in the future as well; see the ongoing discussion in this developer mailing list thread. If you are rather 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 (in the draft stage, see jep:14[]). Some stories: General availability of Windows images. Support for more platforms (AArch64, IBM s390x, PowerPC). Switching to AdoptOpenJDK. 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. Regarding the agent terminology cleanup outside Docker images, we will keep working on this project in the Advocacy & Outreach SIG. If you see the usage of the obsolete "slave" term anywhere in the Jenkins organization (Web UI, documentation, etc.), please feel free to submit a pull request or to report an issue in the jira:JENKINS-42816[Slave to Agent renaming leftovers] EPIC. There are "just" 3000 occurences left in the jenkinsci GitHub organization, but we will get there. Any contributions will be appreciated!

One of the things we loved about going to developer conferences was meeting Jenkins users — newbies and old-timers alike — who are excited to talk about their projects and share tips on how to move forward using Jenkins. Since the coronavirus pandemic, we’re learning to rely more on new ways to gather, and it’s happening via Jenkins online meetups, GitHub collaborations, and Twitter threads, to name a few. It’s a significant change. But what hasn’t changed is the need to share stories about the things users have built, the solutions they’ve developed, and the excellent results they’re getting from some really innovative Jenkins implementations. Then we wondered, why isn’t anyone collecting these user stories and sharing them with the Jenkins community. Introducing Jenkins is the Way So we took the first step to record and archive all the great stuff everyone in our community is building with Jenkins. This way, Jenkins users old and new can come to an archive and search for Jenkins solutions for inspiration. We foresee a vast library of solutions from all around the world, solving a wide array of challenges in every industry imaginable. We decided to call this archive " Jenkins Is The Way" and host it at https://JenkinsIsTheWay.io. To aggregate all these stories, we built a simple online questionnaire so that Jenkins users can submit their own experience using this leading open source automation server. With so many plugins to support building, deploying, and automating your projects, we expect to see a vast collection of stories. We’ve already received a handful, including stories that illustrate how Jenkins Is The Way : to code your own release pipelines to cast magic of continuous delivery to understand and simplify your software lifecycle to accelerate automation in the cloud to facilitate day-to-day work Add your story. Show your Jenkins pride. Get our T-shirt Be an inspiration to the Jenkins community by sharing your Jenkins story. Just go to this link and fill out the form. We’ll ask you about your project’s goals, the technical challenges you overcame with Jenkins, and the solutions you created. It should take no more than 20-30 minutes to complete. We’ll clean it up for clarity and publish it on https://JenkinsIsTheWay.io. Once it’s part of our archive, we’ll send you our new 2020 Jenkins Is the Way t-shirt. And since the more, the merrier, please share this blog post with peers and colleagues. We want to hear everyone’s stories about the clever ways Jenkins is used to automate all that we need to do. Thanks and Acknowledgement Special thanks to abConsulting for creating and managing the https://JenkinsIsTheWay.io site and for reviewing, editing, and publishing the submitted stories. Thanks to the Jenkins Advocacy and Outreach SIG for their reviews and feedback. Thanks also to CloudBees for sponsoring the " Jenkins is the Way" program.

This blogpost was updated to reflect the general availability of the feature after the release of GitHub Branch Source 2.7.1 on April 26th, 2020. I’m excited to announce support for authenticating as a GitHub app in Jenkins. This has been a long awaited feature by many users. It has been released in GitHub Branch Source 2.7.1 which is now available in the Jenkins update centers. Authenticating as a GitHub app brings many benefits: Larger rate limits - The rate limit for a GitHub app scales with your organization size, whereas a user based token has a limit of 5000 regardless of how many repositories you have. User-independent authentication - Each GitHub app has its own user-independent authentication. No more need for 'bot' users or figuring out who should be the owner of 2FA or OAuth tokens. Improved security and tighter permissions - GitHub Apps offer much finer-grained permissions compared to a service user and its personal access tokens. This lets the Jenkins GitHub app require a much smaller set of privileges to run properly. Access to GitHub Checks API - GitHub Apps can access the the GitHub Checks API to create check runs and check suites from Jenkins jobs and provide detailed feedback on commits as well as code annotation Getting started Install the GitHub Branch Source plugin, make sure the version is 2.7.1 or above. Configuring the GitHub Organization Folder Follow the GitHub App Authentication setup guide. These instructions are also linked from the plugin’s README on GitHub. Once you’ve finished setting it up, Jenkins will validate your credential and you should see your new rate limit. Here’s an example on a large org: How do I get an API token in my pipeline? In addition to usage of GitHub App authentication for Multi-Branch Pipeline, you can also use app authentication directly in your Pipelines. You can access the Bearer token for the GitHub API by just loading a 'Username/Password' credential as usual, the plugin will handle authenticating with GitHub in the background. This could be used to call additional GitHub API endpoints from your pipeline, possibly the deployments api or you may wish to implement your own checks api integration until Jenkins supports this out of the box. Note: the API token you get will only be valid for one hour, don’t get it at the start of the pipeline and assume it will be valid all the way through Example: Let’s submit a check run to Jenkins from our Pipeline: pipeline { agent any stages{ stage('Check run') { steps { withCredentials([usernamePassword(credentialsId: 'githubapp-jenkins', usernameVariable: 'GITHUB_APP', passwordVariable: 'GITHUB_ACCESS_TOKEN')]) { sh ''' curl -H "Content-Type: application/json" \ -H "Accept: application/vnd.github.antiope-preview+json" \ -H "authorization: Bearer ${GITHUB_ACCESS_TOKEN}" \ -d '{ "name": "check_run", \ "head_sha": "'${GIT_COMMIT}'", \ "status": "in_progress", \ "external_id": "42", \ "started_at": "2020-03-05T11:14:52Z", \ "output": { "title": "Check run from Jenkins!", \ "summary": "This is a check run which has been generated from Jenkins as GitHub App", \ "text": "...and that is awesome"}}' https://api.github.com/repos/ / /check-runs ''' } } } } } What’s next GitHub Apps authentication in Jenkins is a huge improvement. Many teams have already started using it and have helped improve it by giving pre-release feedback. There are more improvements on the way. There’s a proposed Google Summer of Code project: GitHub Checks API for Jenkins Plugins. It will look at integrating with the Checks API, with a focus on reporting issues found using the warnings-ng plugin directly onto the GitHub pull requests, along with test results summary on GitHub. Hopefully it will make the Pipeline example below much simpler for Jenkins users :) If you want to get involved with this, join the GSoC Gitter channel and ask how you can help.

2020 is going to be a year of change for me. By the end of January, I’ll be officially stepping back from Jenkins, switching my role at CloudBees to an advisor, and turning attention to my new startup. The rest of this post is to contextualize this transition, because if you haven’t been working closely with me, this might come across as a surprise. Jenkins has been an amazing journey that never stopped giving. I have loved it all - especially meeting the users around the world who made Jenkins what it is today. As the creator of the project, at some point I started wondering how to pass the torch to the next leaders, how to get people to step up and drive it forward. Today, thanks to CloudBees and the community, there is a new generation of talented and capable leaders who are passionately driving things forward - and it’s been great to see. Newly elected board members, Jenkins X folks, just to name a few. These new people bring new culture and new code, and altogether it has created a positive jolt that pushed Jenkins out of a local optimum I talked about. They have all my support and respect. In reality, my involvement with Jenkins lately has already been largely symbolic, a little bit like an emperor of Japan or a queen of the UK. That’s why this announcement has little practical impact on the forward motion of Jenkins. Several years ago, I used to feel like the sky would fall down if I stepped aside. Somewhere in 2019, I suddenly noticed that I wasn’t feeling like that at all anymore. The shift was gradual and steady, so I’m not sure exactly when I crossed the threshold, but in 2019 it was clear I was on the other side. That’s how I knew I could finally end this chapter of my life. 15 years with Jenkins and 9 years with CloudBees. That is a long time. I hope you will be wondering what is my new chapter. I’m launching a new startup, Launchable, with my old time buddy Harpreet Singh. I have known him since my days at Sun Microsystems and JavaEE, and he was my partner in crime at CloudBees to build the Jenkins business from scratch. He went to Atlassian running its BitBucket business for a while, but now he and I are back sitting side by side again. A number of CloudBees people invested, including Sacha Labourey, Bob Bickel, and John Vrionis. Through Jenkins and CloudBees, I was able to push the state of automation forward in software development. Such automation is producing a lot of data, but we are not using that data to improve our lives. It truly is a wasted gold mine. Launchable is working on harnessing that information to improve developer productivity. I wrote a separate blog post to discuss more about my thinking. Lastly, even though I’m moving on from CloudBees as a full-time employee, I’m not completely going away. I’ll be still in the CloudBees orbit, as an advisor. I’m still very much invested both emotionally and financially in CloudBees. I’m still a big fan, and I’ll continue to cheer for them, but from the sideline. The same with Jenkins. I’m still on the governance board, ensuring the continuity. I’m also still on the Technical Oversight Committee of the Continuous Delivery Foundation, though my chairperson term will expire in March. I’m incredibly grateful for the undeserved opportunity and the privilege given to me during this chapter. I was surrounded by wonderful, inspiring, and talented people, from whom I learned a lot. I can only hope that I was able to make a positive impact, and give something back in return to them. I won’t name names, but you know who you are, and we’ll stay in touch. This year is going to be truly exciting for me. To infinity and beyond!!

In addition to WAR files and Docker images, the Jenkins project provides native installers for each weekly and LTS release. There are installers available for Linux distributions, Windows, macOS and other operating systems. There are also installers provided by third parties. You can find the list of these installers on the Downloads page. In this blog post, we announce the upcoming deprecation of the macOS native installer. We will review the replacement options and the rollout plan. Why? Maintaining installers is a significant maintenance effort for the project because installers require testing and, sometimes, specific platforms and environments for packaging. When installers lose relevance for the majority of the Jenkins audience, we remove them or handover maintenance to third parties on other areas. For macOS, there are currently two types of packages: native installers with GUI for desktop versions and Homebrew packages. Since Homebrew is now a defacto standard package manager for macOS users, from the Jenkins standpoint it made sense to deprecate the native installers. Why now? There is ongoing work on automating Jenkins Core releases within the Jenkins infrastructure. Long story short, we are moving Jenkins release pipelines to Kubernetes on Microsoft Azure. This environment does not offer macOS machines that are needed to produce native installers. If you are interested to know more, there will be a How Jenkins Builds and Delivers Jenkins in the Cloud talk presented by Olivier Vernin at DevOps World | Jenkins World 2019 Europe in Lisbon (use the JWFOSS code for a 30% discount!). We could have used an external service for building macOS installers, but it would have added an additional point of failure and implementation/maintenance overhead. So we discussed it in the developer mailing list and agreed that it is better to just deprecate and then remove the packages. Replacing native installers In the case of macOS, there are two main alternatives available: managing the service manually or migrating to Homebrew packages. Before doing a migration, we highly recommend backing up your instance. Managing Jenkins with WAR file on macOS If your Jenkins instance was previously set up with a native installer, to update Jenkins it will be enough to replace the jenkins.war file in the installation directory and restart the instance. The services will keep running as it was configured before the migration. The default installation directory is /Applications/Jenkins/jenkins.war Managing Jenkins with Homebrew Installing Jenkins with Homebrew is a way to go for those who want to install Jenkins using a package manager. There are two Homebrew formulas for Jenkins: jenkins for Weekly releases and jenkins-lts for LTS ones. These packages are supported by a third party (Homebrew community), and they may be not as frequently updated as packages supported by the Jenkins project directly. Before doing a migration from macOS Native installers to HomeBrew, please make sure to backup your Jenkins instance. There are no automatic migration tools available, and the installation may corrupt your JENKINS_HOME or service configuration files in edge cases. If you switch to Homebrew, you will need to properly migrate the JENKINS_HOME data to the new location. We do not provide an official migration guide, but it is possible to find some guidelines on the Web. Sample commands: Install the latest Weekly version: brew install jenkins Install a specific Weekly version: brew install jenkins@YOUR_VERSION Start the Jenkins service: brew services start jenkins Restart the Jenkins service: brew services restart jenkins Update the Jenkins version: brew upgrade jenkins For more information see the documentation for Homebrew packages on the macOS Download pages. Rollout plan macOS native packaging is considered as deprecated starting from Jenkins 2.206 and Jenkins LTS 2.204.1 For Jenkins Weekly macOS native packaging will be removed with the switch to the new Jenkins release flow. The exact date is to be determined. After the change, there will be no macOS native installers produced for new Jenkins Weekly releases Releases for previous versions will be available in this archive For Jenkins LTS macOS will be removed with the switch to the new Jenkins release flow in the LTS baseline. This change will happen only after the deployment of the new release flow in Jenkins Weekly. After the switch, there will be no macOS native installers produced for new Jenkins LTS releases Releases for previous versions will be available in this archive See the discussion on the developer mailing list for more information. Questions and feedback If you have any questions or want to provide feedback, please use the developer mailing list thread mentioned above Platform SIG channels (chat, google group). Any feedback will be much appreciated because we plan more installer/ and platform deprecations in the future.