Recent Blog Posts

10 years ago, the Jenkins ruby-runtime was first released. It was an experiment to let plugins be written in ruby but still get integrated into the main Java Virtual Machine runtime with help of JRuby. A similar extension was made to allow plugins to be written in Python but still integrated into the Java Virtual Machine with Jython. Over the years though, the experiments are no longer being maintained and the plugins that use the non-Java runtimes take a lot of compatibility effort. In addition, the Jenkins ruby runtime does not support Java 11. Specifically, the last few years have been really hard on the Jenkins core developers, as they still have to maintain all the hacks and processes to keep the non-Java runtimes barely working. Examples of the experienced issues include compatibility with jep:200[Switch Remoting/XStream blocklist to a permitlist] where we had to allow many Ruby Runtime classes in the Jenkins core to support serialization of data. In 2018 we discussed the future of the Ruby Runtime based plugins. There was a consensus that we want to deprecate and remove the plugins so that Jenkins users do not experience issues . Daniel Beck created jep:7[Deprecation of ruby-runtime] for that. Over the years, the functionality provided by Ruby plugins has been largely replaced by other implementations, and hence we have decided to proceed with the deprecation ( discussion). One month from now, January 22nd, 2022, the default Jenkins update center will stop distributing the Ruby runtime plugin, the plugins that use the Ruby runtime, the Python runtime plugin, and the plugin that uses the Python runtime. What does this mean for you? If you are one of the few users who are using the following plugins, there will be no impact on your existing instances. The only change will come for new installs. Suspended plugins will stay installed, but can not be newly installed without manually downloading releases or using custom update centers. Jenkins plugin management tools and distributions may be affected as well if they use the default update center to download the plugins and/or their metadata. It includes but is not limited to the official Docker images, Helm charts, Jenkinsfile Runner, Custom Jenkins WAR Packager, and the Plugin Installation Manager CLI Tool. Note that all these tools allow custom update sites to be configured if required. The lists below provide additional information about the plugins based on the Ruby Runtime and the Python Runtime. Please plan your transition away from these plugins. They will be removed from the official Jenkins update centers on January 22, 2022. Affected plugins Gitlab Hook Last released 6 years ago. Contains multiple security vulnerabilties. Suggestion: Use the GitLab plugin and the GitLab Branch Source plugin. Cucumber Last released 9 years ago. Suggestion: Use sh or bat to run cucumber from the command line. pyenv Last released 7 years ago. Suggestion: Use sh or bat to run pyenv from the command line. Rvm Last released 5 years ago. Suggestion: Use sh or bat to run rvm from the command line. Capitomcat Last released 7 years ago. Suggestion: Install Ruby and Capistrano and use sh or bat to invoke them from the command line. Commit Message Trigger Last released 7 years ago. Suggestion: Use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps. Git notes Last released 10 years ago. Suggestion: Use sh, bat, or other scripts to run git to annotate commits. rbenv Last released 6 years ago. Suggestion: Use sh or bat to run rbenv from the command line. Chef Last released 6 years ago. Suggestion: Use sh or bat to run chef from the command line. CI Skip Last released 8 years ago. Suggestion: Use the GitHub Commit Skip SCM Behaviour, Bitbucket Commit Skip SCM Behaviour, or SCM Skip to skip builds based on the content of commit messages. Alternately, use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps. InstallShield Last released 8 years ago. Suggestion: Use sh, bat, or other scripts to run InstallShield. MySQL Job Databases Last released 7 years ago. Suggestion: Use Jenkins Job Database Manager Plugin for MySQL. Pathignore Last released 10 years ago. Suggestion: Use the path ignore features of various plugins or use sh, bat, or other scripts to read git commit messages and conditionally execute Pipeline steps. Perl Last released 9 years ago. Suggestion: Use sh or bat to run perl from the command line. pry Last released 10 years ago. Suggestion: Use the Jenkins groovy console and its interface from the Jenkins command line interface. Single Use Agent Last released 7 years ago. Suggestion: Use cloud agents ( Fargate, Azure Container Instances, Docker, etc.) to allocate agents for a single use and then release them. Travis YML Last released 5 years ago. Suggestion: Rewrite the travis.yml file as a Jenkinsfile, a Jenkins Templating Engine file, a Pipeline as YAML, or a Jenkins Modular Pipeline Library. Yammer Last released 8 years ago. Suggestion: Use the Yammer REST API to post messages. DevStack Last released 9 years ago. Ikachan Last released 10 years ago. Jenkinspider Last released 7 years ago. Perl Smoke Test Last released 7 years ago. buddycloud Last released 8 years ago. Acknowledgements We would like to thank all contributors and maintainers who contributed to the Ruby Runtime based plugins and the Python Runtime based plugin. We also thank those who participated in development of new plugins replacing the functionality. These contributors helped millions of Jenkins users while the ecosystem was supported over the past 10 years and it is not taken for granted. Now we need to move on so that we can keep expanding the Jenkins architecture and developers tools. We invite all contributors to participate in this effort and to help us to migrate the plugins to supported JVM-based platforms for plugins. My instance is affected, what to do next? If you do not use the affected plugins, the recommendation is to remove them. Otherwise, it is recommended to start migration out of the plugins to alternatives providing similar functionality. Not all plugins have alternatives. At the moment the Jenkins core team does not plan to provide a replacement, but any contributions are welcome. If you depend on the functionality, we recommend reaching out to the community in the developer mailing list so that you can coordinate the replacement with other affected users.

A critical security vulnerability has been identified in the popular "Apache Log4j 2" library. This vulnerability is identified as CVE-2021-44228. Log4j in Jenkins The Jenkins security team has confirmed that Log4j is not used in Jenkins core. Jenkins plugins may be using Log4j. You can identify whether Log4j is included with any plugin by running the following Groovy script in the Script Console : org.apache.logging.log4j.core.lookup.JndiLookup.class.protectionDomain.codeSource If this results in the following error, Log4j is not included in any installed and enabled plugin: groovy.lang.MissingPropertyException: No such property: org for class: Script1 Otherwise, the script output will print one location where Log4j is found, which includes the plugin name in the path. That plugin should be disabled or uninstalled, followed by a Jenkins restart and another script execution until the "No such property" error appears. Affected plugins and their mitigation status are listed in the Jenkins issue tracker. See this Jira Epic for components known to be affected. Log4j in web application containers If you are hosting your Jenkins in a separate web application container like Tomcat, Websphere, or Glassfish, check with the providers of those containers to assess if they are using a vulnerable version of Log4j. When Jenkins runs from the Docker image, a native installer package (deb, rpm, msi), or is invoked with java -jar jenkins.war, it is not running inside a separate web application container. It is using the built-in Jetty web application container that is bundled inside Jenkins and does not include Log4j. Log4j in Jenkins project infrastructure The Jenkins infrastructure team is currently checking all Jenkins project infrastructure for the presence of vulnerable versions of the Log4j library. This work is ongoing. We may decide to disable some services temporarily out of an abundance of caution. You can see the status of services on the status page.

A continuous integration environment is a mixed bag of machines, platforms, build toolchains and operating systems. Ideally, you want as much flexibility as possible in managing these environments. You want your build machines to be interchangeable and you don’t want to tie your builds to a particular machine. Using containers as build agents is an effective way to get the flexibility you need to create applications faster and more effectively. Most modern software organizations recognize the benefits of deploying and managing applications as containers. And now more organizations are using containers to unify their build and test environments across machines, and to provide an efficient mechanism for deploying applications. If you’re new to containers, think of it as the next step beyond virtualization. It consists of a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. A container image contains everything it needs to run independently of the server on which it lives: It contains a copy of the operating system, along with your application. That could include a database, code, configuration files, dependencies, and so forth. Containerization is a great way to simplify migration of Jenkins instances to different machines, as well as simplify ongoing maintenance and upgrades. Starting with versions 2.5 and higher, Jenkins Pipeline has built-in support for interacting with Docker from within a Jenkinsfile. Although you can install and upgrade Jenkins using OS-installable packages, the container images of Jenkins take installation and upgrades to a new level, removing a lot of the complications with maintaining the Jenkins installation. That’s one of the main reasons you should prefer the container images of Jenkins over OS-specific installation packages. Using containers as build agents for greater Pipeline flexibility What about using containers in your build agents? You’ll recall that Jenkins agents are the "workers" that perform operations requested by the Jenkins controller. What is a Jenkins agent? Many of you have been writing Jenkins pipelines for awhile, but you’ve been constrained by the tooling that’s available on your agent. But what if you no longer had to be constrained by specific versions of specific tools on specific agents? And that you had full control over the tooling that you’re using just by having Docker available on your agents? Well, that is exactly what’s possible by using containers as build agents for Jenkins. To learn how to set up your agents with Docker, watch this step-by-step video. How to Setup Docker Containers As Build Agents for Jenkins So why would you want to use a container as your build agent? As a pipeline author, it gives you the ability to define the tools and the specific versions of those tools that you want to use in your pipeline so that those items are not being mandated or managed by others. Secondly, if in your environment, someone else has to install the tools for you on your agent, you can completely bypass all of that because you’re able to dynamically bring in the tools that you want or need at runtime. Finally, it gives you the chance to experiment with different tools without having to make a long-term commitment to those tools. Because if you have a dependency on someone else installing tools for you, that might take a long time. But by running it as a container, you can test it out, and if it works, great! Then you have the option to work with somebody else to get static versions of those tools installed on your agents, or you can just stay with your container-based build agents. Thanks to our Sponsor Darin works for CloudBees. CloudBees helps Fortune 1000 enterprises manage and scale Jenkins. Thanks to CloudBees for sponsoring the creation of this blog post.

The Jenkins community has recently completed the 2021 elections. On behalf of the Jenkins community and the elections committee, we congratulate all newly elected board members and officers! We also thank all candidates and voters who participated this year. Election results: Mark Waite joins the re-elected Oleg Nenashev and Kohsuke Kawaguchi, Gavin Mogan and Ewelina Wilkosz on the Jenkins Governance Board Tim Jacomb will continue in the role of Release Officer (uncontested) Alyssa Tong will become the new Events Officer (uncontested) Damien Duportal was elected as the Infrastructure Officer (uncontested) Wadeck Follonier was elected as the Security Officer (uncontested) Mark Waite was re-elected in the role of Documentation Officer for another term The board positions and officer roles are an essential part of Jenkins' community governance and well-being, and we are excited to see contributors taking these roles. The board continues to require that no single company may have a majority on the Jenkins governance board. Oleg Nenashev is employed by Dynatrace, while Mark is employed by CloudBees. Governance Board election details This year we had three candidates participating in Jenkins Governance Board elections: Mark Waite, Oleg Nenashev (returning), and Ullrich Hafner (returning) All of them are awesome community leaders who actively contribute to the Jenkins project and represent its users. It would be an honor to have them on the Jenkins board. Regardless of the election results, we appreciate their participation and the time they invested in these elections. This year we were electing 2 governance board members. We were using the Condorcet Internet Voting Service that allows voters to rank their choices rather than just picking their one favorite choice. You can find full voting results here : Mark Waite (Condorcet winner: wins contests with all other choices) Oleg Nenashev loses to Mark Waite by 37–22 Ullrich Hafner loses to Mark Waite by 42–14, loses to Oleg Nenashev by 37–15 Congratulations to the returning Oleg, and the newly elected Mark, and thanks to Ullrich for his past contributions. All new board members are elected for a 2-year term unless they decide to step down earlier. The estimated end of the term for them is December 02, 2023. Officer election details All 5 officer positions were up for election this year. These roles have a 1-year term, with the estimated end of term on Dec 02, 2022. After the initial review of nominations and confirmations with potential candidates, 4 officer positions were uncontested: Tim Jacomb - Release Officer Alyssa Tong - Events Officer Damien Duportal - Infrastructure Officer Wadeck Follonier - Security Officer Documentation Officer election results Mark Waite won the biggest support as a Documentation officer ( voting results). Mark will continue as Documentation Officer. Mark Waite (Condorcet winner: wins contests with all other choices) Saeid Bostandoust loses to Mark Waite by 46–9 Thanks to all Jenkins officers for their continued leadership! Officers take responsibility for many day-to-day processes in the Jenkins community and lead the contributor teams working on them. It requires significant time commitment, and it is not taken for granted. Statistics This year we had 81 registered voters and around 59 actual votes. Feedback The Jenkins project plans to conduct elections every year. We appreciate and welcome feedback regarding the election process so that we can improve the process. We have started a Retrospective document for these elections. Everyone can suggest changes in this document, and we will integrate them. If you have any private feedback you would like to share, please send an email to the Jenkins Board. If you would like to raise any issues about the election process, please contact one of the elected Governance Board members.

This year, the Duchess community embraced a new challenge: working on women’s presence in Open Source while participating in Jenkins during the Hacktoberfest, a yearly event. Huge congrats to all the contributors! 🥳 Note: This blog is a translation, the source blog post is located here https://www.duchess-france.org/duchess-hacktoberfest-2021/ Anne-Laure Gaillard Interview Hello Anne-Laure, can you introduce yourself? LinkedIn After a PhD in Computer Science and a few years in Software Development, I specialized in software quality assurance, and particularly in the testing domain. I’m a supporter of the doctrine: “Quality is everyone’s business”. Fond of agility, I’m part of the organization committee of the Agile Tour Bordeaux since 2020. I also like to engage in sporting challenges: I swam across the Garonne (a big river in the south of France) and finished 2 triathlons. Keeping the best for the end: I’m the mother of two kids who taught me it’s possible to speak about Pokemon with one, while drawing a unicorn with the other. What did you think about Open Source, and maybe Jenkins, before starting the hackathon? During my studies, I met quite a lot of “nerds / geeks” contributing to Linux distributions (Gentoo & Debian). Their technical skills seemed higher than mine and the Open Source universe looked inaccessible to me. Concerning Jenkins, I am a user (now contributor) of it, but not an administrator. What motivated you to participate in that hackathon? I dared to participate thanks to the Duchess (and mainly Angélique, thanks to her). Having the support and backing of the community was my motivation. What will you remember from this experience? From a professional point of view, I perfected my knowledge of Git, and I had a chance to overview part of the quality processes from Open Source projects. My first Pull Request was approved by… 9 people! The fourth reviewer did find an issue. Who can tell me code review isn’t useful now? From a personal perspective, I remember two things. The first one: Open Source communities are not elitist communities. Every contribution matters, even small ones. The people I met were positive and benevolent. The second one could be illustrated by a quote from Grace Hopper: “If it’s a good idea, go ahead and do it. It’s much easier to apologize than it is to get permission.”. Do you have anything more to say? After Jenkins, I also submitted Pull Requests to others Open Source projects. The problem: with such a diversity of Open Source projects, how to organize your time? Anne-Laure Gaillard contributions during hacktoberfest https://github.com/jenkinsci/jenkins/pull/5779 https://github.com/jenkinsci/jenkins/pull/5785 https://github.com/jenkinsci/jenkins/pull/5804 https://github.com/jenkinsci/jenkins/pull/5806 https://github.com/jenkinsci/jenkins/pull/5807 https://github.com/jenkinsci/jenkins/pull/5808 https://github.com/jenkinsci/jenkins/pull/5822 https://github.com/jenkinsci/jenkins/pull/5823 https://github.com/mattermost/quality-assurance/pull/25 https://github.com/mattermost/quality-assurance/pull/23 https://github.com/sarequl/Netflix-Helper/pull/6 Bertha Torres Interview Twitter: @tatoberres LinkedIn Hello Bertha, can you introduce yourself? Coming from a literature training and as a language teacher for more than 15 years, it’s while moving to a high mountain area that a need to explore other skills set in. Thus, a self-taught training followed by a validated file for financing diploma training followed one another and confirmed to me that life is too short to waste it on what does not make sense to us. What did you think about Open Source, and maybe Jenkins, before starting the hackathon? Participating in Open Source appeared to me in that exploratory process like a learning opportunity… which I thought was inaccessible of course! I didn’t see myself writing code. But thanks to the Duchess France community, I learned how to contribute at my level and to understand the contribution process. It’ll allow me as things progress to contribute in more domains. Can you tell us how the woman version of Jenkins was born? Well… In the presentation video for Hacktoberfest, the artwork was mentioned ( https://www.jenkins.io/artwork/) and Angélique also mentioned it during the first meeting… And one must admit that looking at it, you can see a lot of different things but women. So I imagined a governess, very confident, efficient, very clever, scrupulously combed, nicely dressed, who might represent the personality of what Jenkins is made of. Do you have anything to add? This time I was able to participate through Pull Requests related to translation and drawing. I’ll probably do it again! Bertha Torres contributions during hacktoberfest https://github.com/jenkins-infra/jenkins.io/pull/4627 https://github.com/jenkinsci/jenkins/pull/5796 https://github.com/jenkinsci/jenkins/pull/5797 https://github.com/jenkinsci/workflow-job-plugin/pull/214 https://github.com/jenkinsci/workflow-job-plugin/pull/215 https://github.com/jenkinsci/ant-plugin/pull/78 https://github.com/jenkinsci/ant-plugin/pull/77 Pauline Iogna’s Interview Twitter: @pauline_io Hello Pauline, can you introduce yourself? I’m a backend developer in Java/Scala, and an active member of Duchess France. What did you think about Open Source, and maybe Jenkins, before starting the hackathon? I didn’t really have an opinion about Jenkins before doing the hackathon. Like many other people, I’m a Jenkins user but I didn’t know its source code. What motivated you to participate in this hackathon? Actually participating in Hacktoberfest. Just bringing a contribution, even modest, on an open source project. What did you discover through that hackathon? Technically, I discovered how to do MVC with Apache Jelly. I also rediscovered the contribution process of Open Source projects. The Hacktoberfest mechanism is really well thought out for onboarding people wanting to start working on Open Source projects. With Angélique’s help on top of that to animate sessions on the Duchess France Slack channel, we had the best conditions to contribute to that important project. What will you remember from this experience? It’s not that simple to contribute to a project you’re just discovering, it requires a bit of investment and patience. On Jenkins, the contributors are really reactive and the Pull Requests are quickly reviewed. The feedback is useful and benevolent. There is one Jira project listing all the features and bugs to be worked on for the project. Some tickets are flagged as “newbie” allowing those who are beginners to pick easily and quickly doable tickets. Pauline Iogna contributions https://github.com/jenkinsci/jenkins/pull/5835 https://github.com/jenkinsci/jenkins/pull/5793 A few words about the organization within Duchess France The framework was intentionally simple and flexible. We started with an online kick start meeting for describing a bit of context, and more precisely the Jenkins universe. Online kick start meeting for context Then, we mainly exchanged through the Duchess Slack channel in an asynchronous way on a dedicated channel, as well as a 30 minutes meeting each Friday during October.

Summary Jenkins bundles Guava, a core Java library from Google. Beginning with Jenkins 2.320 (released on November 10, 2021), Jenkins has upgraded the Guava library from 11.0.1 (released on January 9, 2012) to 31.0.1 (released on September 27, 2021). Plugins have already been prepared to support the new version of Guava in JEP-233. Use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.320. Motivation Many security-conscious organizations using, or planning to use, Jenkins run off-the-shelf security scanners to look for known vulnerabilities. These commonly flag the obsolete Guava library as susceptible to a serialization-related vulnerability ( CVE-2018-10237) and recommend upgrading. While Jenkins uses JEP-200 to form an explicit list of allowed classes for deserialization, and the two Guava classes affected by CVE-2018-10237 are not and will never be added to the list, it is time-consuming for the security team to respond to purported security reports and for users to justify exemptions from policy to use Jenkins anyway. Furthermore, the decade-old version of Guava has long been a maintenance burden for Jenkins developers. In a world where Dependabot offers upgrades to libraries released just hours before, it is unpleasant to be working with dependencies that are many years old. For more information, see JEP-233. Upgrading The vast majority of plugins have already been prepared to support the new version of Guava in JEP-233. Jenkins users need only upgrade plugins to compatible versions as documented in the "Released As" field in Jira. It is critical to use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.320. Failure to upgrade plugins to compatible versions may result in ClassNotFoundException, NoClassDefFoundError, or other low-level Java errors. Reporting issues If you find a regression in a plugin, please file a bug report in Jira: Open JEP-233 issues When reporting an issue, include the following information: Use the JEP-233 label. Provide the complete list of installed plugins as suggested in the bug reporting guidelines. Provide the complete stack trace, if relevant. Provide steps to reproduce the issue from scratch on a minimal Jenkins installation; the scenario should fail when the steps are followed on Jenkins 2.320 or later and pass when the steps are followed on Jenkins 2.319 or earlier. If you maintain a Jenkins plugin with an open JEP-233 issue, then please check if there is a pull request awaiting merge or release. If you use an unmaintained Jenkins plugin with an open JEP-233 issue, consider stepping up and adopting the plugin to release a compatible version. Conclusion We expect to see a bit of disruption from these changes but hope that in the long run they will save time for core and plugin developers and lead to a more secure and stable tool. Please reach out on the developers' list with any questions or suggestions.

Hacktoberfest 2021 made great contributions to the Jenkins project. We thank all the Hacktoberfest contributors and the maintainers who reviewed the submitted pull requests. We received contributions in artwork, translation, documentation, security, and general purpose improvements. The contributions included software improvements, documentation updates, and video tutorials. Translations and Artwork Duchess France provided significant improvements to the French localization of Jenkins. The changes included new translations of text, corrections of existing translations, and file encoding fixes. The translation changes included fifteen pull requests representing the work of six different contributors. Translation pull requests were also received for Spanish language improvements. The translation pull requests included multiple plugins in addition to Jenkins core. A contributor from"Duchess France [Women in tech]" created the first Jenkins logo highlighting a woman. Special thanks to tatoberres for the new artwork! Thea Mushambadze created the new Jenkins logo for Georgia logo. Thanks very much! Plugin Docs Migration to GitHub The Jenkins project started the migration of plugin documentation to GitHub almost two years ago. Hacktoberfest 2021 identified 40 candidate plugins to migrate their documentation to GitHub. Dan Heath, Deepak Gupta, Avinash Upadhyaya K R, Rajan Kumar Singh, and Dheeraj Singh Jodha provided a total of 29 pull requests migrating plugin documentation to GitHub. Special thanks to the contributors and to the plugin maintainers that merged and released documentation migration pull requests. Eight plugins have fully migrated their documentation to GitHub through Hacktoberfest contributions. An additional thirteen plugins have merged the documentation change and will complete the migration with their next plugin release. The plugin documentation migration was coordinated through a worksheet. A tutorial video describing the documentation migration process is also available. Implementing Content Security Policy Wadeck Follonier provided a tutorial to prepare Jenkins for a broader implementation of Content Security Policy. Six contributors provided pull requests to Jenkins core to create separate JavaScript files from JavaScript that was previously implemented inside the Jenkins 'jelly' files. Moving JavaScript into separate files prepares Jenkins to implement Content Security Policy protections against JavaScript embedded in HTML. Jenkins Architecture Diagrams Angélique Jard provided architectural diagrams showing a dataflow view of Jenkins and a high level view of Jenkins. Those diagrams help others understand the internal structure of Jenkins and how it interacts with users and with other systems. Modernizing Plugins Video Series Darin Pope created five videos illustrating some of the small steps that a new contributor can use to help modernize a plugin. Additional plugin modernization and adoption ideas are included in the"Contributing to Open Source" workshop from DevOps World 2021. Modernizing Jenkins Plugins Thanks to All We offer our most sincere thanks to all Hacktoberfest contributors and to the many pull request reviewers.

In common CI/CD use-cases a lot of the space is consumed by test reports. This data is stored within JENKINS_HOME, and the current storage format requires huge overheads when retrieving statistics and, especially, trends. In order to display trends, each report has to be loaded and then processed in-memory. The main purpose of externalising Test Results is to optimize Jenkins performance and storage by querying the desired data from external storages. I’m please to announce that the JUnit Plugin external storage is now available for use. Getting started Install your database vendor specific plugin, you can use the Jenkins plugin site to search for it: https://plugins.jenkins.io/ui/search/?labels=database e.g. you could install the PostgreSQL Database plugin. We currently support PostgreSQL or MySQL, but can support others, just create an issue or send a pull request. From Jenkins UI Navigate to: Manage Jenkins → Configure System → Junit In the dropdown select 'SQL Database' Now configure your Database connection details. Search for 'Global Database' on the same 'Configure System' page. Select the database implementation you want to use and click 'Test Connection' to verify Jenkins can connect Click 'Save' Configuration as code If you want to configure the plugin via Configuration as Code then see the below sample: unclassified: globalDatabaseConfiguration: database: postgreSQL: database: "jenkins" hostname: "${DB_HOST_NAME}" password: "${DB_PASSWORD}" username: "${DB_USERNAME}" validationQuery: "SELECT 1" junitTestResultStorage: storage: "database" Using the plugin Now run some builds, here’s an example pipeline configuration to get you started if you’re just trying out the plugin: node { writeFile file: 'x.xml', text: ''' ''' junit 'x.xml' } You will see a test result trend appear like below on the builds project page: If you check on the controller’s file system you will see no junitResult.xml for new builds. If you connect to your database and run: SELECT * FROM caseresults; You will see a number of test results in the database. What happens to existing test results? Existing test results will stay on disk but will not be loaded. Currently there is no migration scripts or plugin functionality to do this, if you need it then please raise an issue. How are test results cleaned up When a job or build is deleted the related test results are removed. This is expected to be done as part of a 'Build Discarder'. If you wish to keep your results longer than this you can disable this feature by enabling: Skip cleanup of test result on build deletion on the system configuration page. If you need more complex cleanup strategies built into the plugin then please raise an issue. API The API is defined at: jenkinsdoc:junit:io.jenkins.plugins.junit.storage.JunitTestResultStorage[] jenkinsdoc:junit:io.jenkins.plugins.junit.storage.JunitTestResultStorageDescriptor[] jenkinsdoc:junit:io.jenkins.plugins.junit.storage.TestResultImpl[] JunitTestResultStorage#load is passed a job name and build which can be used to construct an instance of the external storage implementation. This implementation will then act on that job and build except for the optimised calls that act across all builds. The API contains the basic methods like getFailCount, getSkipCount, but also APIs that are optimised for retrieving data for the trend graphs on the job page and the test result history page. These allow single API calls to be made for what used to be a lot of work for Jenkins to look up before. Feedback I would love to hear your feedback & suggestions for this feature. Please create an issue at https://github.com/jenkinsci/junit-plugin or provide feedback on https://community.jenkins.io