Recent Blog Posts

Since 2017, I started to do some contributions to the Jenkins community. As a beginner, translation might be the easiest way to help the project. You don’t need to understand the whole context, even to create a ticket in the issue tracker system. Improvement of localization usually is minor. But some problems occurred soon, there isn’t a native speaker of Chinese that could review my PRs. So, sometimes my PRs are delayed from being merged into master. Some contributors told me that I can start a thread at the mailing list. Normally, discussing at the mailing list is the open source community way. We got a lot of ideas for the localization from there. As a result, we achieved some goals that I’d like to share here. JEP-216 Previously, language localization files were distributed in core and in each plugin. For this proposal, each language has a single localization plugin, such as Chinese Localization plugin. Finally, Localization Support Plugin and Chinese Localization plugin are able to support all types of localization resource files. From the plugins website, you can see that there are already 13 000 installations. We removed all Chinese localization files at the PR-4008. I really appreciate Daniel Beck for helping me to add localization support, Liam Newman helping me to review JEP-216, and many other community members. Chinese Localization SIG We believe that this SIG could help to improve Jenkins experience for Chinese users and gather more contributors from China. This SIG is responsible for maintaining the Chinese Jenkins website, promoting the Jenkins community in China in the social media with WeChat account. We publish translated blog articles, Jenkins release notes, JAM or other events at the WeChat account. For now, there are 1800 followers that can read our news from the last half a year. Especially, I want to say thanks to Wang Donghui, Zhai Zhijun, and other contributors. They did a lot of contributions. I wish I could see more and more folks join us.

Implementing DevSecOps practices at the enterprise scale is challenging. With multiple programming languages, automated testing frameworks, and security compliance tools being used by different applications within your organization, it becomes difficult to build and maintain pipelines for each team. Most pipelines are going to follow the same generic workflow regardless of which specific tech stack is employed by an application. The Templating Engine Plugin (abbreviated as JTE for Jenkins Templating Engine) allows you to capture this efficiency by creating tool-agnostic, templated workflows to be reused by every team. As technology consultants with clients in both the public and private sectors, at Booz Allen we found ourselves building DevSecOps pipelines from scratch for every new project. Through developing the Jenkins Templating Engine, we’ve seen pipeline development decrease from months to days now that we can reuse tool integrations while bringing a new level of governance to Jenkins pipelines. Pipeline Templating Organizations benefit from letting application developers focus on what they do best: building applications. Supporting this means building a centralized DevOps team responsible for maintaining platform infrastructure and creating CI/CD pipelines utilized by development teams. With the rise of microservice-based architectures, a centralized DevOps teams can support many different development teams simultaneously; all of whom may be leveraging different programming languages and automated testing tools. While the tools may differ between development teams, the workflow is often the same: unit test, static code analysis, build and publish an artifact, deploy it, and then perform different types of testing against the deployed application. The Templating Engine Plugin allows you to remove the Jenkinsfile from each repository by defining a common workflow for teams to inherit. Instead of an entire pipeline definition in each repository, teams supply a configuration file specifying which tools to use for the workflow. JTE in Action Let’s walk through a bare bones example to demonstrate the reusability of templates: Example Pipeline Template: unit_test() build() static_code_analysis() Templates leverage Steps contributed by Libraries to outline a workflow teams must implement. While a template does get executed just like any other Jenkinsfile (meaning that the standard scripted and declarative syntax is supported), the goal of a template should be to read like plain English and avoid any technical implementation. Leveraging templates in this way lets you separate the business logic (what should happen when) of your pipeline from the technical implementation (what’s actually going to happen). The result of this is a CI/CD pipeline that’s proven to be significantly easier to manage when supporting multiple teams simultaneously. The steps outlined by this template ( unit_test, build, and static_code_analysis) have been named generically on purpose. This way teams can specify different libraries to use while sharing the same pipeline. Implementing the Template Implementing a shareable pipeline with the Templating Engine requires a few key components: Pipeline Template : Outline the workflow to be performed Libraries : Provide technical implementations of the steps of the workflow Configuration Files : Specify which libraries to use and their configuration Step 1: Create a Pipeline Configuration Repository A Pipeline Configuration Repository is used to store common configurations and pipeline templates inherited by teams. This example Pipeline Configuration Repository will later be configured as part of a Governance Tier : the mechanism in JTE that allows you to build hierarchical configurations representing your organization. A Governance Tier holds three things: Pipeline Templates A list of Library Sources The tier’s configuration file ( pipeline_config.groovy) The pipeline templates and the configuration file for a Governance Tier are stored in the pipeline configuration repository. When configuring the Governance Tier in Jenkins, you will provide a source code management location for a repository that contains the above components as well as the base directory where these artifacts can be found. Step 2: Create the Pipeline Template Next, we’ll create a Jenkinsfile for the Governance Tier. In JTE, the Jenkinsfile is the default pipeline template that an execution will use. Jenkinsfile unit_test() build() static_code_analysis() Step 3: Create the Libraries The Templating Engine Plugin has implemented a version of Jenkins Shared Libraries to enhance the reusability of libraries. A library is a root directory within a source code repository that has been configured as a Library Source on a Governance Tier. In our example, the pipeline template needs to perform unit testing, package an artifact, and run static code analysis. Let’s assume that we have some teams using gradle and some teams using maven to build and test their application but they will both use SonarQube to perform static code analysis. In this scenario, we should create gradle, maven, and sonarqube libraries. |- gradle/ \-- build.groovy \-- unit_test.groovy |- maven/ \-- build.groovy \-- unit_test.groovy |- sonarqube/ \-- static_code_analysis.groovy Step 4: Implement the Steps Implementing a library step is exactly the same as just writing regular global variables as part of the default Jenkins Shared Libraries. For the purposes of this demonstration, we will just have each step print out the step name and contributing library. gradle/build.groovy void call(){ println "gradle: build()" } Read more about Library Development within JTE. Step 5: Create the Configuration Files The configuration file for JTE is named pipeline_config.groovy. In the Governance Tier we’ll create a configuration file specifying common configurations between the applications. In this case, both applications are using the sonarqube library: pipeline_config.groovy libraries{ merge = true // allow individual apps to contribute additional libraries sonarqube } Next, we’ll create two more repositories representing the maven and gradle applications. Within those repositories all we’ll need is an application-specific pipeline_config.groovy file. These repositories both contain an application pipeline_config.groovy configuration file. maven app: pipeline_config.groovy libraries{ maven } gradle app: pipeline_config.groovy libraries{ gradle } Step 6: Configure the Governance Tier in Jenkins Now that we have a Pipeline Configuration Repository and a Library Source Repository, we can configure a Governance Tier in Jenkins: This configuration shown in the image above can be found under Manage Jenkins >> Configure System Through the Templating Engine, you can create a pipeline governance hierarchy matching your organization’s taxonomy by representing this structure via Folders in Jenkins. Step 7: Create a Multibranch Pipeline for Both Applications When creating Multibranch Pipeline Projects for each app, the Templating Engine plugin supplies a new Project Recognizer called Jenkins Templating Engine. This sets the project to use the Templating Engine framework for all branches within the repository. You can also set the Jenkins Templating Engine project recognizer for a GitHub Organization project, enabling you to easily share the same pipeline across an entire Github Organization! Step 8: Run the Pipelines That’s it! Now, both applications will leverage the exact same pipeline template while having the flexibility to select which tools should be used during each phase of the workflow. Below is sample output from the console log from both applications pipeline runs: Gradle: [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-configuration [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-app-gradle.git [JTE] Loading Library sonarqube from git https://github.com/steven-terrana/example-jte-libraries.git [JTE] Loading Library gradle from git https://github.com/steven-terrana/example-jte-libraries.git ... [JTE] Obtained Template Jenkinsfile from git https://github.com/steven-terrana/example-jte-configuration [JTE][Step - gradle/unit_test] [Pipeline] echo gradle: unit_test() [JTE][Step - gradle/build] [Pipeline] echo gradle: build() [JTE][Step - sonarqube/static_code_analysis] [Pipeline] echo sonarqube: static_code_analysis() [Pipeline] End of Pipeline Maven: [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-configuration [JTE] Obtained Template Configuration File pipeline_config.groovy from git https://github.com/steven-terrana/example-jte-app-maven.git [JTE] Loading Library sonarqube from git https://github.com/steven-terrana/example-jte-libraries.git [JTE] Loading Library maven from git https://github.com/steven-terrana/example-jte-libraries.git ... [JTE] Obtained Template Jenkinsfile from git https://github.com/steven-terrana/example-jte-configuration [JTE][Step - maven/unit_test] [Pipeline] echo maven: unit_test() [JTE][Step - maven/build] [Pipeline] echo maven: build() [JTE][Step - sonarqube/static_code_analysis] [Pipeline] echo sonarqube: static_code_analysis() [Pipeline] End of Pipeline Benefits of the Templating Engine Apply Organizational Governance Leveraging the Templating Engine Plugin will allow you to define enterprise-scale, approved workflows that can be used by teams regardless of what tools are being used. This top-down approach makes scaling and enforcing DevSecOps principles significantly easier within your organization. Optimize Code Reuse There’s really no need for every team in your organization to figure out how to do the same things over and over again. At Booz Allen, we have seen pipeline development time decrease from months to days as we have continuously reused and expanded upon our Templating Engine library portfolio as part of our Solutions Delivery Platform. Simplify Pipeline Maintainability Often DevOps engineers find themselves building and supporting pipelines for multiple development teams at the same time. By decoupling the workflow from the technical implementation and consolidating the pipeline definition to a centralized location, the Templating Engine plugin allows DevOps engineers to scale much faster. Get Involved! The Templating Engine Plugin has been open sourced and made available in the Jenkins Update Center. We always appreciate feedback and contributions! If you have an interesting use case or would like to ask questions, try the templating-engine-plugin on Gitter. Advanced Features Configuration File Conditional Inheritance Externalize Library Configurations Aspect Oriented LifeCycle Hooks Multiple Pipeline Templates Default Step Implementation Configuration File DSL Sandboxing More Resources For this Demonstration Pipeline Configuration Repository Sample Libraries Sample Maven Repository Sample Gradle Repository Additional Resources Templating Engine Documentation Source Code Booz Allen’s SDP Pipeline Libraries Booz Allen Hamilton

Half a year ago we delivered a security fix for Jenkins that had the potential to break the entire Jenkins UI. We needed to change how Jenkins, through the Stapler web framework, handled HTTP requests, tightening the rules around what requests would be processed by Jenkins. In the six months since, we didn’t receive notable reports of problems resulting from this change, and it’s thanks to the telemetry we gathered beforehand. The Problem Jenkins uses the Stapler web framework for HTTP request handling. Stapler’s basic premise is that it uses reflective access to code elements matching its naming conventions. For example, any public method whose name starts with get, and that has a String, int, long, or no argument can be invoked this way on objects that are reachable through these means. As these naming conventions closely match common code patterns in Java, accessing crafted URLs could invoke methods never intended to be invoked this way. A simple example of that is a URL every Jenkins user would be familiar with: /job/jobname. This ends up invoking a method called #getJob(String), with the argument being"jobname", on the root application object, and having it handle the rest of the URL, if any. Of course, this is a URL intended to be accessed this way. How about invoking Object#getClass(), followed by Class#getClassLoader(), by accessing the URL /class/classLoader? While this particular chain would not result in a useful response, this doesn’t change that the methods were invoked. We identified a number of URLs that could be abused to access otherwise inaccessible jobs, or even invoke internal methods in the web application server to invalidate all sessions. The security advisory provides an overview of the issues we’d identified by then. The Idea To solve this problem inherent in the Stapler framework’s design, we defined rules that restrict invocation beyond what would be allowed by Stapler. For example, the declared return type of getters now needed to be one defined in Jenkins core or a Jenkins plugin and have either clearly Stapler-related methods (with Stapler annotations, parameter types, etc.) or Stapler-related resource files associated with it. Otherwise, the type wouldn’t be aware of Stapler, and couldn’t produce a meaningful response anyway. This meant that getters just declaring Object (or List, Map, etc.) would no longer be allowed by default. It was clear to the developers working on this problem that we needed the ability to be able to override the default rules for specific getters. But allowing plugin developers to adapt their plugins after we published the fix wasn’t going to cut it; Jenkins needed to ship with a comprehensive default whitelist for methods known to not conform to the new rules, so that updating would not result in problems for users. The Solution While there is tooling like Plugin Compatibility Tester and Acceptance Test Harness, many Jenkins plugins do not have comprehensive tests of their UI — the Jenkins UI is fairly stable after all. We did not expect to have sufficient test coverage to deliver a change like this with confidence. The only way we would be able to build such a comprehensive whitelist would be to add telemetry to Jenkins. While Jenkins instances periodically report usage statistics to the Jenkins project, the information included is very bare bones and mostly useful to know the number of installations, the popularity of plugins, and the general size of Jenkins instances through number and types of jobs and agents. We also didn’t want to just collect data without a clear goal, so we set ourselves some limitations — collect as little data as possible, no personally identifiable information, have a specific purpose for each kind of information we would collect, and define an end date for the collection in advance. We defined all of this in JEP-214, created the Uplink service that would receive submissions, and added the basic client framework to Jenkins. The implementation is fairly basic — we just submit an arbitrary JSON object with some added metadata to a service. This system would inform tweaks to a security fix we were anxious to get out, after all. Starting in mid October for weekly releases, and early November for LTS, tens of thousands of Jenkins instances would submit Stapler request dispatch telemetry daily, and we would keep identifying code incompatible with the new rules and amending the fix. Ultimately, the whitelist would include a few dozen entries, preventing serious regressions in popular plugins like Credentials Plugin, JUnit Plugin, or the Pipeline plugins suite, down to Google Health Check Plugin, a plugin with just 80 installations when we published the fix. Learning what requests would result in problems also allowed us to write better developer documentation — we already knew what code patterns would break, and how popular each of them was in the plugin ecosystem. The Overhaul I wrote above: For example, the declared return type of getters now needed to be one defined in Jenkins core or a Jenkins plugin and have either clearly Stapler-related methods (with Stapler annotations, parameter types, etc.) or Stapler-related resource files associated with it. While this was true for the fix during most of development, it isn’t how the fix that we published actually works. About a month before the intended release date, internal design/code review feedback criticized the complicated and time-consuming implementation that at the time required scanning the class path of Jenkins and all plugins and looking for related resources, and suggested a different approach. So we tried to require that the declared type or any of its ancestors be annotated with the new annotation @StaplerAccessibleType, annotated a bunch of types in Jenkins itself ( ModelObject being the obvious first choice), and ran our scripts that check to see whether Stapler would be allowed to dispatch methods identified in telemetry. We’d long since automated the daily update of dispatch telemetry processing, so it was a simple matter of changing which Jenkins build we were working with. After a few iterations of adding the annotation to more classes, the results were very positive: Very few additional types needed whitelisting, while many more were no longer (unnecessarily) allowed to be dispatched to. This experiment, late during development, ended up being essentially the fix we delivered. We didn’t need to perform costly scanning of the class path on startup — we didn’t need to scan the class path at all — , and the rules governing request dispatch in Stapler, while different from before, are still pretty easy to understand and independent of how components are packaged. The Outcome As usual when delivering a fix we expect could result in regressions in plugins, we created a wiki page that users could report problems on. Right now, there’s one entry on that wiki page. It is one we were aware of well before release, decided against whitelisting it, and the affected, undocumented feature in Git Plugin ended up being removed. The situation in our issue tracker is only slightly worse, with two apparently minor issues having been reported in Jira. Without telemetry, delivering a fix like this one would have been difficult to begin with. Tinkering with the implementation just a few weeks before release and having any confidence in the result? Not causing any significant regressions? I think this would simply be impossible.

Today we published a security advisory that mostly informs about issues in Jenkins plugins that have no fixes. What’s going on? The Jenkins security team triages incoming reports both to Jira and our non-public mailing list. Once we’ve determined it is a plugin not maintained by any Jenkins security team members, we try to inform the plugin maintainer about the issue, offering our help in developing, reviewing, and publishing any fixes. Sometimes the affected plugin is unmaintained, or maintainers don’t respond in a timely manner to the notifications or the followup emails we send. In such cases, we publish security advisories informing users about these issues, even if there’s no new release with a fix. Doing so allows administrators to make an informed decision about the continued use of plugins with unresolved security vulnerabilities. Today’s advisory is overwhelmingly such an advisory. See a plugin you love on this list and want to help out? Learn about adopting plugins.

As a software engineer, for many years I have used open source software (frameworks, libraries, tools…​) in the different companies I have worked at. However, I had never been able to engage in an open-source project as a contributor, until now. Since I made my first—​ridiculously simple—​commit into Jenkins, six months ago (in September, 2018), I have been attempting to contribute more to the Jenkins project. However, contributing to open-source projects is, in general, challenging. Especially to long-lived projects, with a lot of history, legacy code and tribal knowledge. It is often difficult to know where to start and also difficult to come up with a plan to keep moving forward and contributing regularly, and in more meaningful ways over time. When it comes to the Jenkins project, I have encountered challenges that others trying to get into the community are likely to encounter. For that reason, I have decided to go ahead and share my journey of becoming a more engaged Jenkins contributor. I plan to publish roughly 1 post per month, describing this journey. I will attempt to start contributing to the pieces that are easier to start with, transitioning towards more complex contributions over time. Where to start jenkins.io To become a Jenkins contributor, the most obvious place to start looking at is jenkins.io. In the top navbar there is a Community dropdown, with several links to different sections. The first entry, Overview, takes us to the “Participate and contribute” section. In this section we get lots of information about the many ways in which we can engage with the Jenkins project and community. Even though the intention is to display all the possible options, allowing the reader to choose, it can feel a bit overwhelming. The page is divided into two columns, the column on the left shows the different options to participate, while the column on the right shows the different options to contribute. Suggestions to Participate In the left column of the “Participate and contribute” page, there are several ideas on how to engage with the community, ranging from communicating to reviewing changes or providing feedback. One of the pieces that got me confused at first in this area were the communication channels. There are many different channels for communication. There are several mailing lists and there are also IRC and Gitter channels. During my first attempts to get involved, I subscribed to many of the mailing lists and several IRC and Gitter channels, but I quickly noticed that there is significant communication going on; and that most threads in the most active lists and channels are specific to issues users or developers have. So, unless your goal is to support other users right away (if you are an experienced Jenkins user already it might be the case) or you plan to ask questions that you already have in mind, I would advise against spending too much time on this at first. Even though it is great to see how the community members support each other, the amount of communication might be overwhelming for a newcomer, and if you are also trying to contribute to the project (either with translations, documentation or code), following these conversations might not be the best way to start. Suggestions to Contribute In the right column of the “Participate and contribute” page there are several ideas on how to contribute, mostly grouped into: writing code, translating, documenting and testing. In following posts, I will be going through all of these types of contributions, as well as through some of the suggestions to participate, which include reviewing Pull Requests (PRs) or providing feedback (either reporting new issues or replicating cases other users have already described, providing additional information to help the maintainer reproduce and fix them). My first contribution in this journey When looking at the “Participate and contribute” page, I noticed a couple of things in that page that I could help improve. And I was actually planning to pick one of those as the first example of a contribution for this post. But when I was reading the contributing guidelines of the repository, I found an even easier contribution I could make, which I thought would be a great example to illustrate how simple it could be to start contributing. So I decided to go ahead with it. The website repository In the ”Document” section there is a link to the contributing guidelines of the jenkins.io repository. The CONTRIBUTING file is a common file present in the root folder of most open-source-project repositories. Following the link to that file, I reached the jenkins.io repository, which is the one that contains the sources for the corresponding website—​which also includes this blog. And, in fact, the contributing file was the first file I wanted to review, in order to learn more about how to contribute to the website. Found a broken link When reading the contributing file, I learned about the Awestruct static site generator, which is the tool used to transform the AsciiDoc source files in the repo into a website. However, when I clicked the link to learn more about it, I noticed it was broken. The domain had expired. Why not fix it? This was the opportunity I chose to show other newcomers how easy it can be to start contributing. Forking the repository The first step, as usual, would be to fork the repository and clone it to my machine. Applying the change The next step would be to apply the change to the corresponding file. To do so, I created a new branch “alternative-awestruct-link” and applied the change there: Making sure everything builds correctly and tests pass Even though in this case my contribution was not to the actual website, but to the contributing guidelines (and for that reason was unlikely to break anything), it is a best practice to get used to the regular process every contribution should follow, making sure everything builds correctly after any change. As stated in the contributing guidelines themselves, in order to build this repository we just have to run the default “make” target, in the root of the repository. Once the command execution finishes, if everything looks good, we are ready to go to the next step: creating the PR. Creating the PR Once my change had been committed and pushed to my repository, I just had to create the PR. We have an easy way to do so by just clicking the link that we get in our git logs once the push is completed, although we can create the PR directly through the GitHub UI, if we prefer so; or even use “hub”, the GitHub CLI, to do it. In this case, I just clicked the link, which took me to the PR creation page on GitHub. Once there, I added a description and created the PR. When a PR to this repository is created, we notice there are some checks that start running. Jenkins repositories are configured to notify the “Jenkins on Jenkins”, which runs the corresponding CI pipelines for each repository, as described in the corresponding Jenkinsfile. Once the checks are completed, we can see the result in the PR: And if we want to see the details of the execution, we can follow the “Show all checks” link: PR Review Now that the PR has been created and all automated checks are passing, we only have to wait for peer code reviews. Once someone approves the PR and it is later merged, your contribution is integrated into the master branch of the repository, becoming part of the next release. I have contributed! This contribution I made is a trivial one, with very little complexity and it might not be the most interesting one if you are trying to contribute code to the Jenkins project itself. However, for me, as the contributor, it was a great way to get familiar with the repository, its contributing guidelines, the technology behind the jenkins.io website; and, above anything else, to start “losing the fear” of contributing to an open source project like Jenkins. So, if you are in the same position I was, do not hesitate. Go ahead and find your own first contribution. Every little counts!

Over the past three months, I have been mentoring two Outreachy interns, David and Latha, with my co-mentor, Jeff Thompson. Our project was to introduce a standardized way for creating an audit log of Jenkins and plugins using Apache Log4j Audit. While this type of feature is addressed by other existing plugins, there is no unifying way for plugins to contribute their own actions. This project provided ample opportunities for each of our interns to experience the community processes for starting a new Jenkins plugin, contributing changes to Jenkins itself in order to support more audit event types, using CICD principles, and developing a Jenkins Enhancement Proposal to begin the standardization process of audit logging throughout the ecosystem. During this internship, David and Latha contributed several aspects of the project, much of which lays the foundation for easily instrumenting more subsystems and plugins with audit logs. A template log4j2.xml file is used for allowing more complex logging output configurations with a configuration UI. New APIs have been introduced in Jenkins to allow for more authentication-related events to be audited by the plugin. Audit events have been defined for a few authorization scenarios and some build events. For example, here is a snippet of audit log output for a build execution in the JSON layout: { "thread" : "Executor #0 for master : executing test #1", "level" : "OFF", "loggerName" : "AuditLogger", "marker" : { "name" : "Audit", "parents" : [ { "name" : "EVENT" } ] }, "message" : "Audit [buildStart buildNumber=\"1\" cause=\"[Started by user anonymous]\" projectName=\"test\" timestamp=\"Mon Mar 25 13:48:09 CDT 2019\" userId=\"SYSTEM\"]", "endOfBatch" : false, "loggerFqcn" : "org.apache.logging.log4j.audit.AuditLogger", "instant" : { "epochSecond" : 1553539689, "nanoOfSecond" : 810000000 }, "contextMap" : { }, "threadId" : 54, "threadPriority" : 5 } { "thread" : "Executor #0 for master : executing test #1", "level" : "OFF", "loggerName" : "AuditLogger", "marker" : { "name" : "Audit", "parents" : [ { "name" : "EVENT" } ] }, "message" : "Audit [buildFinish buildNumber=\"1\" cause=\"[Started by user anonymous]\" projectName=\"test\" timestamp=\"Mon Mar 25 13:48:10 CDT 2019\" userId=\"SYSTEM\"]", "endOfBatch" : false, "loggerFqcn" : "org.apache.logging.log4j.audit.AuditLogger", "instant" : { "epochSecond" : 1553539690, "nanoOfSecond" : 155000000 }, "contextMap" : { }, "threadId" : 54, "threadPriority" : 5 } Best of all, this project has helped instill important software engineering values such as automated testing and continuous delivery. As we conclude this round, we look forward to participating in the next Outreachy internship to continue this project and grow the community. For more information about the next round, check out the Outreachy website.

Today Linux Foundation, along with CloudBees, Google, and a number of other companies, launched a new open-source software foundation called Continuous Delivery Foundation (CDF.) The CDF believes in the power of Continuous Delivery, and it aims to foster and sustain the ecosystem of open-source, vendor neutral projects. Jenkins contributors have decided that our project should join this new foundation. This discussion happened over a period of time, with a relatively succinct summary of the motivation comes from here. Now, as a user, what does this mean? First, there will be no big disruption/discontinuity. The same people are still here, no URL is changing, releases will come out like they’ve always been. We will make the decisions the same way as we’ve been making, and pull requests land the same way. Changes will happen continuously over the period of time. This is yet another testament to the maturity and the importance of the Jenkins project in this space. With a quarter million Jenkins running around the globe, it’s truly rocking the world of software development from IoT to games, cloud native webapps to machine learning projects. It makes Jenkins such an obvious, safe choice for anyone seeking open heterogeneous DevOps strategy. The CDF creates a level playing field that is well-understood to organized contributors, which further, translate into more contributors, hence resulting in a better Jenkins, faster. Over the past years, the Jenkins project has been steadily growing more structures that provide this clarity, and this is the newest step on this trajectory. Any serious dev teams are combining multiple tools and services to cover the whole software development spectrum. A lot of work gets reinvented in those teams to integrate those tools together. Jenkins will be working more closely with other projects under the umbrella of the CDF, which would result in better aligned software with less overlap. Our users are practitioners trying to improve the software development process in their organizations. They get that CI/CD/automation which unlocks the productivity that their organizations need, but that’s not always obvious to their organizations as a whole. So our users often struggle to get the necessary support. The CDF will advocate for the practice of Continuous Delivery, and because it’s not coming from a vendor or a project, it will reach the people who can lend that support. So I hope you can see why we are so excited about this! In fact, for us, this is an idea that we’ve been cooking for close to two years. I don’t think I’m exaggerating much to say the whole idea of the CDF started from the Jenkins project. A lot of people have done so much work behind the scene to make this happen. But a few people played such instrumental roles that I have to personally thank them namely, Chris Aniszczyk for his patience and persistence, R. Tyler Croy for cooking and evolving the idea, and Tracy Miranda for bringing this idea into a reality.

This is a joint blog post prepared by the Java 11 Support Team: Adrien Lecharpentier, Ashton Treadway, Baptiste Mathus, Jenn Briden, Kevin Earls, María Isabel Vilacides, Mark Waite, Ramón León and Oleg Nenashev. We have worked hard for this and it’s now here. We are thrilled to announce full support for Java 11 in Jenkins starting from Jenkins 2.164 (released on Feb 10, 2019) and LTS 2.164.1 (ETA: March 14th). This means you can now run your Jenkins controllers and agents with a Java 11 JVM. Starting in June 2018, many events were organized to improve Jenkins code base and add Java 11 support. Beyond these events, Core/Plugins maintainers and many other contributors have worked hard to make sure they discover and solve as many issues as possible related to Java 11 support. The effort to support Java 11 led to the creation of the JEP-211: Java 10+ support in Jenkins. It also spurred the creation of the Platform Special Interest Group to coordinate the Java 11 work and other platform support efforts. Celebration We’d like to take a moment to thank everyone involved in these tasks: code contributors, issue reporters, testers, event planners and attendees and all those in the community who have generously lent their time and support to this effort. Thank you all! Here are some of the contributors who helped with this task (alphabetical order): Alex Earl, Alyssa Tong, Ashton Treadway, Baptiste Mathus, Carlos Sanchez, Daniel Beck, David Aldrich, Denis Digtyar, Devin Nusbaum, Emeric Vernat, Evaristo Gutierrez, Gavin Mogan, Gianpaolo Macario, Isabel Vilacides, James Howe, Jeff Pearce, Jeff Thompson, Jenn Briden, Jesse Glick, Jonah Graham, Kevin Earls, Ksenia Nenasheva, Kohsuke Kawaguchi, Liam Newman, Mandy Chung, Mark Waite, Nicolas De Loof, Oleg Nenashev, Oliver Gondža, Olivier Lamy, Olivier Vernin, Parker Ennis, Paul Sandoz, Ramón León, Sam Van Oort, Tobias Getrost, Tracy Miranda, Ulli Hafner, Vincent Latombe, Wadeck Follonier (We are deeply sorry if we missed anyone in this list.) Guidelines In order to keep it simple, here is how you can start Jenkins on Java 11 using the Docker image. You can select a Java 11 based image by suffixing the tag of the image with -jdk11. If you are upgrading an existing instance please read the Upgrading Jenkins Java version from 8 to 11 page before upgrading. So you can run Jenkins on Java 11 with: docker run -p 50000:50000 -p 8080:8080 jenkins/jenkins:2.164-jdk11 However, and as always, you can still start Jenkins with other methods. Please see the more detailed documentation at Running Jenkins on Java 11. Developer guidelines For developers involved in Jenkins development, you can find details on developing and testing Jenkins to run on Java 11 on the Java 11 Developer Guidelines. This resource regroups the modifications which might need to be done in order to validate the compatibility of plugins for Java 11. What’s next Even though this is a big achievement, we still have work to do. Our first priority is adding Java 11 support to JenkinsFile Runner project. From there, we will move on to port Java 11 support to the Jenkins X project and the Evergreen project. So, even if this is a big deal to us, this is not the end of the story. It is a major step that will benefit users, developers, and members of the Jenkins community. Reference links Running Jenkins on Java 11 https://wiki.jenkins.io/display/JENKINS/Known+Java+11+Compatibility+issues https://wiki.jenkins.io/display/JENKINS/Java+11+Developer+Guidelines jep:211[Java 11 support in Jenkins]