Once again October has arrived. That means the regular Hacktoberfest event is back! This year it will be the fifth installment. During this one-month hackathon you can support open-source and earn a limited edition swag. On behalf of the Jenkins project, we invite you to participate in Hacktoberfest and to work on the project. We welcome all contributors, regardless of their background and Jenkins experience. Quick start Sign-up to Hacktoberfest on the event website. Everything is set, just start creating pull-requests! Contributing to Jenkins There are many ways to contribute to Jenkins during Hacktoberfest. Generally, any pull requests in GitHub may qualify. You can…​ Code - Contribute to the code or automated tests Jenkins project codebase includes dozens of programming languages, mostly Java, Groovy, and JavaScript + Go in Jenkins You can also find components in Ruby/Kotlin, and even native components in C/C++ Document - Improve documentation Blog - write blogposts about Jenkins Localize - Localize Jenkins components Design - artwork and UI improvements also count! Organize - Organize a local meetup for Jenkins & Hacktoberfest (see below) See the Contribute and Participate page for more information. Projects The Jenkins project is spread across several organizations on GitHub (jenkinsci, jenkins-x, jenkins-infra). You are welcome contribute to any repository in any of those organizations, however various components in Jenkins have differing review and delivery velocity. Here is a list of Jenkins subprojects with maintainers who have committed to delivering quick reviews to Hackathon participants. Project/component Ideas and links Jenkins Core There is always something to improve in Jenkins core itself. You can address various issues, improve the codebase, and add new features there. Contributing, newbie-friendly issues Jenkins Website Extend and improve Jenkins documentation, add your own blogpost. Contributing guidelines Jenkins X Try out the project and create new demos, extend documentation, and create new builders for your toolchains. Contributing guidelines, Quick start, creating custom builders, newbie-friendly issues Jenkins Configuration-as-Code Plugin Contribute to the fresh new plugin: improve the codebase, add demos and plugin integrations. Contributing to JCasC Jenkins Evergreen Try and improve the recently released Evergreen project - an automatically updating rolling distribution system for Jenkins. Quick start, newbie-friendly issues. Java 11 support (jep:211[]) Contribute to Jenkins core and plugins to enable Java 11 in future releases. You can help to create new packaging, new features, testing flows, or cleanup issues Illegal Reflective Access in the code. Gitter chat, newbie-friendly issues Docker Packaging Add new features and improvements to Jenkins Docker packaging: Jenkins controller, Agents, and other components. Chinese Localization SIG Contribute to the new Website and the Simplified Chinese Localization plugin. Jenkins Artwork Create new images and logos for Jenkins area meetups, subprojects, and plugins. You can also contribute new graphics to plugins. Note that this is not a full list, and the list will be extended depending on the interest from maintainers. You are welcome to contribute to existing Jenkins plugins…​ and even to create new ones. Local events Hacktoberfest is an online event, but there are many events being organized by open-source communities. You can join one of these events. We also encourage Jenkins Area Meetup organizers to run Jenkins-specific events in October (workshops, hackergartens). If you are not a meetup organizer but want to host a meetup, you can reach out to the organizers via meetup.com resources (you can find a JAM here). Check out the Hacktoberfest Event Kit for more info. FAQ You can find Hacktoberfest FAQ here. Below you can find answer to some Jenkins-specific questions. Q: I am new to Jenkins, how do I start? If you are new to Jenkins, you could start by fixing some small and well described issues. There are lists of such newbie-friendly issues, see the links in the table above. You can also submit your own issue and propose a fix. Q: I want to work on my own plugin, is it fine? Yes, it is fine! Any contributions count, your role in a repository does not matter. Just make sure you create pull requests instead of direct pushes (hint: it’s a best practice if you have a CI configured for your repository). Q: How to find documentation? Jenkins project contains lots of materials about contributing to the project. Here are some links which may help: Participate - landing page for newcomer contributors Plugin Development Tutorials Developer Documentation Gitter channel for Q&A Projects in the table above also have their own documentation to help newcomers. Q: How do I get reviews? All projects in the list above are monitored by their maintainers, and you will likely get a review within few days. Reviews in other repositories and plugins may take longer. In the case of delays, ping us in the hacktoberfest-help channel in Gitter. Unmerged pull-requests also count in Hacktoberfest, so merge delays won’t block you from getting prizes. Q: I am stuck. How do I get help? For non-technical questions (process and general direction) use our hacktoberfest-help channel in Gitter. For technical questions please use the IRC chat, Developer mailing lists, or the main jenkinsci/jenkins channel. Many subprojects also have their own chats. Q: Does Jenkins project send special swag? All participants will get swag from Hacktoberfest organizers if they create at least5 pull requests. Jenkins project may also distribute some swag to top contributors, depending on the budget and contributions.

A few months ago I published a blog post about Cloud Native Special Interest Group (SIG) and ongoing projects related to Cloud Native Jenkins. Next week we will be presenting at DevOps World | Jenkins World together with Carlos Sanchez and Jesse Glick, so I would like to provide a heads up for our talk: “A Cloud Native Jenkins”. In our talk, we will focus on the following topics: Pluggable Storage, our ephemeral Jenkins controllers experiments, and tools which may be used to implement single-shot controllers. Pluggable Storage Pluggable storage is one of the major areas we have been working on over the last few months. There are a number of parallel stories which are summarized on this page. There has been significant progress in the areas of artifact storage, build logging and configuration storage. A number of Jenkins Enhancement Proposals were submitted and accepted, and there are plugin releases and prototypes for these stories. During our talk we will discuss the current status of these stories and future plans. In particular, we will cover the following areas and reference implementations: Storing all your artifacts transparently, e.g. in a cloud service blob store like AWS S3. Artifact Manager for S3 Plugin is an implementation we have recently released Providing credentials from an external location. Kubernetes Credentials Provider is one of the existing implementations for Kubernetes secrets Sending and retrieving the build logs from a cloud service. We are working on reference implementations for AWS CloudWatch Logs and Elasticsearch Storing configuration data in external storage like Kubernetes Resources and SQL database Storing test results externally, e.g. in an SQL database or a specialized Test Management System There are existing plugins for the areas above, but there is a difference in approach we have taken. Instead of creating new custom steps we extend Jenkins architecture in a way that the storage becomes transparent to users. For example, with Artifact Manager for S3 Plugin common Archive Artifacts steps work transparently with Remote storage, as well as Jenkins Pipeline’s stash() / unstash() steps. The reference implementations intentionally use different technologies so that we cover more scenarios. We regularly discuss the implementations in the Cloud Native SIG, and we would appreciate your feedback. Ephemeral Jenkins controllers research Want something new? Several days ago Kohsuke Kawaguchi, the creator of Jenkins, posted the Jenkins: Shifting Gears article to summarize the plan for Jenkins evolution. Cloud Native Jenkins is a critical part of this plan, and it is not “just Jenkins X”. There are various architectural changes in Jenkins required to make this vision happen, and we plan to work on these changes in the Cloud Native SIG. In our presentation, we will talk about our experiment with ephemeral Jenkins and single-shot controllers. In this story we are creating a headless single-shot controller which starts in a container, executes a Pipeline build and pushes all the results to remote storage so that the container can just be deleted after completion. Such a controller bundles plugins and self-configuration logic using “Configuration as Code”, so that it can start executing Pipelines in just a few seconds. Once packaged, it can be invoked from CLI as simply as…​ docker run --rm -v $PWD/demo/Jenkinsfile:/workspace/Jenkinsfile onenashev/cwp-jenkinsfile-runner-demo or, in Kubernetes: kubectl create configmap jenkinsfile --from-file=demo/Jenkinsfile kubectl create -f demo/kubernetes.yaml Such a single-shot controller could also be made a part of a Cloud Native Jenkins system. Standard event handlers like Prow can invoke the builds on webhooks and report results back, so that the single-shot controller can be used to build pull requests or to run Continuous Delivery flows. Extra agents could also be connected to the controller on-demand, using the Kubernetes plugin or sidecar containers. Tools In order to make this experiment possible, we used a toolchain based on Docker, Jenkinsfile Runner, Configuration as Code Plugin (JCasC), and a Custom WAR Packager tool which glues all the things together. Custom WAR Packager is a new tool which takes various configurations (YAML specification defining core version, list of plugins, system properties, Groovy Hooks, JCasC YAMLs)…​ and then bundles everything as a ready-to-fly WAR file or Docker image. Starting from version 1.2, Custom WAR Packager also supports packaging Jenkinsfile Runner images as an experimental feature. I will do a separate blogpost about this new tool later, but there is already some documentation a number of demos in the project’s repo. Our demo Yes, we will have a demo! We will show a single-shot controller running with Pluggable storage implementations for AWS environments (Amazon S3, AWS CloudWatch, EKS, etc.), which executes Jenkins Pipelines for Maven projects and provisions agents in Kubernetes on-demand. The demo has to be published yes, but you can already find a more simple Jenkinsfile Runner demo here. Want to know more? The upcoming DevOps World | Jenkins World conferences are heavily packed with talks related to Cloud Native Jenkins, including war stories and presentations on projects like Jenkins X and Jenkins Evergreen. It is a great chance to get more information about using Jenkins in cloud environments. If you are a Jenkins contributor or just want to become a contributor, also join the Contributor Summit (Sep 17 in US and Oct 23 in Nice) or visit the Jenkins community booth in the Exhibition hall. At the Contributor Summit on Sep 17 we will also have a face-to-face Cloud Native SIG meeting. Feel free to contribute to the agenda here. Come meet Carlos, Jesse, Oleg, and other Cloud Native SIG members at Jenkins World on September 16-19th in San Francisco and on October 22-25 in Nice. register with the code JWFOSS for a 30% discount off your pass.

On large-scale Jenkins instances controller disk and network I/O become bottlenecks in particular cases. Build logging and artifact storage were one for the most intensive I/O consumers, hence it would be great to somehow redirect them to an external storage. Back in 2016 there were active discussions about such Pluggable Storage for Jenkins. At that point we created several prototypes, but then other work took precedence. There was still a high demand in Pluggable Storage for large-scale instances, and these stories also become a major obstacle for cloud native Jenkins setups. I am happy to say that the Pluggable Storage discussions are back online. You may have seen changes in the Core for Artifact Storage ( JEP-202) and a new Artifact Manager for S3 plugin. We have also created a number of JEPs for External Logging and created a new Cloud Native Special Interest Group (SIG) to offer a venue for discussing changes and to keep them as open as possible. Tomorrow Jesse Glick and I will be presenting the current External Logging designs at the Cloud Native SIG online meeting, you can find more info about the meeting here. I decided that it is a good time to write about the new SIG. In this blogpost I will try to provide my vision of the SIG and its purpose. I will also summarize the current status of the activities in the group. What are Special Interest Groups? If you follow the developer mailing list, you may have seen the discussion about introducing SIGs in the Jenkins project. The SIG model has been proposed by R. Tyler Croy, and it largely follows the successful Kubernetes SIG model. The objective of these SIGs is to make the community more transparent to contributors and to offer venues for specific discussions. The idea of SIGs and how to create them is documented in JEP-4. JEP-4 is still in Draft state, but a few SIGs have been already created using that process: Platform SIG, GSoC SIG and, finally, Cloud Native SIG. SIGs are a big opportunity to the Jenkins project, offering a new way to onboard contributors who are interested only in particular aspects of Jenkins. With SIGs they can subscribe to particular topics without following the entire Developer mailing list which can become pretty buzzy nowadays. It also offers company contributors a clear way how to join community and participate in specific areas. This is great for larger projects which cannot be done by a single contributor. Like JEPs, SIGs help focus and coordinate efforts. And, back to major efforts…​ Lack of resources among core contributors was one of the reasons why we did not deliver on Pluggable Storage stories back in 2016. I believe that SIGs can help fix that in Jenkins, making it easier to find groups with the same interests and reach out to them in order to organize activity. Regular meetings are also helpful to get such efforts moving. Points above are the main reasons why I joined the Cloud Native SIG. Similarly, that’s why I decided to create a Platform SIG to deliver on major efforts like Java 10+ support in Jenkins. I hope that more SIGs get created soon so that contributors could focus on areas of their interest. Cloud Native SIG In the original proposal Carlos Sanchez, the Cloud Native SIG chair, has described the purpose of the SIG well. There has been great progress this year in cloud-native-minded projects like Jenkins X and Jenkins Evergreen, but the current Jenkins architecture does not offer particular features which could be utilized there: Pluggable Storage, High Availability, etc. There are ways to achieve it using Jenkins plugins and some infrastructure tweaks, but it is far from the out-of-the-box experience. It complicates Jenkins management and slows down development of new cloud-native solutions for Jenkins. So, what do I expect from the SIG? Define roadmap towards Cloud-Native Jenkins architecture which will help the project to stay relevant for Cloud Native installations Provide a venue for discussion of critical Jenkins architecture changes Act as a steering committee for Jenkins Enhancement Proposals in the area of Cloud-Native solutions Finally, coordinate efforts between contributors and get new contributors onboard What’s next in the SIG? The SIG agenda is largely defined by the SIG participants. If you are interested to discuss particular topics, just propose them in the SIG mailing list. As the current SIG page describes, there are several areas defined as initial topics: Artifact Storage, Log Storage, Configuration Storage All these topics are related to the Pluggable Storage Area, and the end goal for them is to ensure that all data is externalized so that replication becomes possible. In addition to the mentioned data types, discussed at the Jenkins World 2016 summit, we will need to externalize other data types: Item and Run storage, Fingerprints, Test and coverage results, etc. There is some foundation work being done for that. For example, Shenyu Zheng is working on a Code Coverage API plugin which would allow to unify the code coverage storage formats in Jenkins. Once the Pluggable Storage stories are done the next steps are true High Availability, rolling or canary upgrades and zero downtime. At that point other foundation stories like Remoting over Kafka by Pham Vu Tuan might be integrated into the Cloud Native architecture to make Jenkins more robust against outages within the cluster. It will take some time to get to this state, but it can be done incrementally. Let me briefly summarize current state of the 3 focuses listed in the Cloud Native SIG. Artifact Storage There are many existing plugins allowing to upload and download artifacts from external storage (e.g. S3, Artifactory, Publish over SFTP, etc., etc.), but there are no plugins which can do it transparently without using new steps. In many cases the artifacts also get uploaded through the controller, and it increases load on the system. It would be great if there was a layer which would allow storing artifacts externally when using common steps like Archive Artifacts. Artifact storage work was started this spring by Jesse Glick, Carlos Sanchez and Ivan Fernandez Calvo before the Cloud Native SIG was actually founded. Current state: JEP-202 "External Artifact Storage" has been proposed in the Jenkins community. This JEP defines API changes in the Jenkins core which are needed to support External artifact managers Jenkins Pipeline has been updated to support external artifact storages for archive / unarchive and stash / unstash New Artifact Manager for S3 plugin reference implementation of the new API. The plugin is available in main Jenkins update centers A number of plugins has been updated in order to support external artifact storage The Artifact Manager API is available in Jenkins LTS starting from 2.121.1, so it is possible to create new implementations using the provided API and existing implementations. This new feature is fully backward compatible with the default Filesystem-based storage, but there are known issues for plugins explicitly relying on artifact locations in JENKINS_HOME (you can find a list of such plugins here). It will take a while to get all plugins supported, but the new API in the core should allow migrating plugins. I hope we will revisit the External Artifact Storage at the SIG meetings at some point. It would be a good opportunity to do a retrospective and to understand how to improve the process in SIG. Log storage Log storage is a separate big story. Back in 2016 External logging was one of the key Pluggable Storage stories we defined at the contributor summit. We created an EPIC for the story ( JENKINS-38313) and after that created a number of prototypes together with Xing Yan and Jesse Glick. One of these prototypes for Pipeline has recently been updated and published here. Jesse Glick and Carlos Sanchez are returning to this story and plan to discuss it within the Cloud Native SIG. There are a number of Jenkins Enhancement proposals which have been submitted recently: jep:207[] - External Build Logging support in the Jenkins Core jep:210[] - External log storage for Pipeline jep:212[] - External Logging API Plugin jep:206[] - Use UTF-8 for Pipeline build logs In the linked documents you can find references to current reference implementations. So far we have a working prototype for the new design. There are still many bits to fix before the final release, but the designs are ready for review and feedback. This Tuesday (Jul 31) we are going to have a SIG meeting in order to present the current state and to discuss the proposed designs and JEPs. The meeting will happen at 3PM UTC. You can watch the broadcast using this link. Participant link will be posted in the SIGs Gitter channel 10 minutes before the meeting. Configuration storage This is one of the future stories we would like to consider. Although configurations are not big, externalizing them is a critical task for getting highly-available or disposable Jenkins controllers. There are many ways to store configurations in Jenkins, but 95% of cases are covered by the XmlFile layer which serializes objects to disk and reads them using the XStream library. Externalizing these XmlFile s would be a great step forward. There are several prototypes for externalizing configurations, e.g. in DotCI. There are also other implementations which could be upstreamed to the Jenkins core: Alex Nordlund has recently proposed a pull request to Jenkins Core, which should make the XML Storage pluggable James Strachan has implemented similar engine for Kubernetes in the kubeify prototype I also did some experiments with externalizing XML Storages back in 2016 The next steps for this story would be to aggregate implementations into a single JEP. I have it in my queue, and I hope to write up a design once we get more clarity on the External logging stories. Conclusions Special Interest Groups are a new format for collaboration and disucssion in the Jenkins community. Although we have had some work groups before (Infrastructure, Configuration-as-Code, etc.), introduction of SIGs sets a new bar in terms of the project transparency and consistency. Major architecture changes in Jenkins are needed to ensure its future in the new environments, and SIGs will help to boost visibility and participation around these changes. If you want to know more about the Cloud Native SIG, all resources are listed on the SIG’s page on jenkins.io. If you want to participate in the SIG’s activities, just do the following: Subscribe to the mailing list Join our Gitter channel Join our public meetings I am also working on organizing a face-to-face Cloud Native SIG meeting at the Jenkins Contributor Summit, which will happen on September 17 during DevOps World | Jenkins World in San Francisco. If you come to DevOps World | Jenkins World, please feel free to join us at the contributor summit or to meet us at the community booth. Together with Jesse and Carlos we are also going to present some bits of our work at the A Cloud Native Jenkins talk. Stay tuned for more updates and demos on the Cloud-Native Jenkins fronts!

This week we have a Jenkins & Java 10 Online Hackathon. This is an open online event, where we work together on Jenkins core and plugins in order to find and fix compatibility issues, share experiences and have some fun. Everybody is welcome to join, independently of their Jenkins experience and amount of time they have available. After the kick off on Monday Jenkins contributors have been working on Java 10 and Java 11 support in Jenkins. We have already received contributions from 12 hackathon participants, and the number keeps growing. There are still 3 days ahead, but we have already achieved some important results we want to share. Jenkins Pipeline One of our major efforts over last 2 days was to get Jenkins Pipeline working on Java 10+. When the hackathon started Jenkins Pipeline was not working at all, and it was a major blocker for Java support and for exploratory testing in particular. We’ve been working together with Sam van Oort and Devin Nusbaum to fix the libraries in the Jenkins core, Pipeline: Support plugin and Docker packaging. Just to summarize the result of two days in one screenshot…​ Yes, we have got it running! Over two days we have got from the "Pipeline Crashes Immediately" state to the situation when the most of key Pipeline features are operational, including Scripted and Declarative Pipeline, Blue Ocean, shared libraries and dozens of plugins being used in the Jenkins plugin build flow. There is still a lot of work to do to get the changes finalized, but Jenkins Pipeline is available for testing on Java 10 and 11 now. If you want to try it out, you can use a new jenkins/jenkins-experimental:blueocean-jdk10 image we have created. It bundles all the required patches, so you can just run the following command to get started: docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins-experimental:blueocean-jdk10 If you want to try more complex scenarions, see the Running Jenkins with Java 10 and 11 blogpost and List of Required patches. What else? Although Pipeline is the most visible change, there are other ongoing activities: Devin Nusbaum explored plugin startup issues we had with JDK 11ea+17 and confirmed that we need to upgrade our images to JDK 11ea+18 Gianpaolo Macario is working on adopting the Java 10 experimental images in his easy-jenkins project Sam van Oort and Devin Nusbaum are working on getting plugin build and test flows when using JDK 10 with Maven Nicolas de Loof is working on cleaning up Illegal reflective access warnings in Jenkins components, using the new Fields micro-library Olivier Lamy and Nicolas de Loof are updating the Animal Sniffer plugin for Maven to make it compatible with Java 9 and above Kohsuke Kawaguchi has released a repackaged version of ASM 6.2 we use in the project Last but not least, Liam Newman and Tracy Miranda helped us a lot to run the meetings and to get this hackathon organized There are also other contributors working on exploratory testing and reporting defects they discover. See our status doc for the full list. What’s next? Tomorrow we will have 2 sessions: At 8AM UTC we will have a sync-up. According to the requests from hackathon paticipants, we will have an intro session to Jenkins development for newcomers YouTube link At 4PM UTC we will have a meeting with key JDK Project Jigsaw committers Mark Reinhold, Mandy Chung and Paul Sandoz will join us to talk about Java 10/11 adoption YouTube link We will also post participant links in our Gitter channel 15 minutes before the meetings. If you have any questions, please join the meetings or raise questions in the chat during the call. Can I still join the hackathon? Yes, you can! It is possible to hop in and hop off at any time. Just respond to the registration form, join our Gitter channel and start hacking/testing. We also have a number of newbie-friendly issues you can start from. See our Kick-off session and slides for quick start guidelines. Links Developer mailing list Hackathon sync-up document Running Jenkins with Java 10 and 11 Jenkins Online Meetup page

Please refer to Running Jenkins on Java 11 documentation to have the up-to-date details on how to run Jenkins on Java 11. Guidelines in this blogpost are rendered obsolete by the Java 11 Support Preview Availability announcement on Dec 13, 2018 and by the Java 11 GA release on Sep 25, 2018. See the Java support page for up-to-date information about running Jenkins with Java 11. The Jenkins project also no longer ships preview versions for Java 10. As you probably know, we will have a Jenkins and Java 10+ online hackathon this week. In order to enable early adopters to try out Jenkins with new Java versions, we have updated Jenkins core and Docker packages. Starting from Jenkins 2.127, weekly releases can be launched with Java 10 and Java 11 (preview). Although there are some known compatibility issues, the packages are ready for evaluation and exploratory testing. This article explains how to run Jenkins with Java 10 and 11 using Docker images and WAR files. It also lists known issues and provides contributor guidelines. Running in Docker In order to simplify testing, we have created a new jenkins/jenkins-experimental repository on DockerHub. This repository includes various Jenkins Core images, including Java 10 and Java 11 images. We have also set up development branches and continuous delivery flows for Jenkins core, so now we can deliver patches for these images without waiting for weekly releases. You can run the image simply as: docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins-experimental:latest-jdk11 The following tags are available: 2.127-jdk10, 2.128-jdk10 - Weekly releases packaged with Java 10 2.127-jdk11, 2.128-jdk11 - Weekly releases packaged with Java 11 latest-jdk10 - Jenkins core build from the java10-support branch latest-jdk11 - Automatic build from the core’s java11-support branch. blueocean-jdk10, blueocean-jdk11 - Experimental build, which bundles all Jenkins Pipeline and Blue Ocean patches required to run on Java 11. If you want to try Pipeline, use this image Java 10/11 images are fully compatible with the official jenkins/jenkins Docker image documentation, e.g. you can use plugins.txt to install plugins, mount volumes and pass extra options via environment variables. Running Jenkins without Docker Java 10 Download Jenkins WAR for 2.127 or above (or build the experimental branch) Run WAR with the following command: ${JAVA10_HOME}/bin/java --add-modules java.xml.bind -jar jenkins.war \ --enable-future-java --httpPort=8080 --prefix=/jenkins Java 11 Download Jenkins WAR for 2.127 or above (or build the experimental branch) Download the following libraries to the same directory as jenkins.war jaxb-api-2.3.0.jar (save as jaxb-api.jar) jaxb-core-2.3.0.1.jar (save as jaxb-core.jar) jaxb-impl-2.3.0.1.jar (save as jaxb-impl.jar) javax.activation v.1.2.0 (save as javax.activation.jar) Run the following command: Run Jenkins with ${JAVA11_HOME}/bin/java \ -p jaxb-api.jar:javax.activation.jar --add-modules java.xml.bind,java.activation \ -cp jaxb-core.jar:jaxb-impl.jar \ -jar jenkins.war --enable-future-java --httpPort=8080 --prefix=/jenkins Current state As of June 17, we have achieved the following state: Jenkins 2.127+ starts up successfully with OpenJDK 10.0.1 and OpenJDK 11+17-Debian-2 (preview) It is possible to configure and run simple Freestyle jobs Jenkins agents are able to start on Java 10, to connect to the controller and to execute Freestyle jobs Agents can be connected using Docker Plugin and Yet Another Docker Plugin Job DSL plugin works well on demo projects Maven Integration plugin can build plugin-pom -based Jenkins plugins when running on agents with JDK 8 It is possible to create Folders and manage items in them It is possible to configure Jenkins using Configuration-as-Code plugin Jenkins is able to execute Groovy scripts in Script Console and Groovy Hooks Known issues So far we know about the following issues: Pipeline crashes immediately on Java 10 and 11 ( JENKINS-46602) Workaround: Pipeline: Support plugin should be updated to version 3.0-java11-alpha-1-rc684.d802f5d9aeed from the Incrementals repo ( download) FIXED - Git Client plugin 2.7.2 cannot be installed when running with Java 11 build 18ea There are many warnings about Illegal reflective access during execution (linked in JENKINS-40689). In current Java 10 and 11 releases it does not lead to failures, but we want to cleanup these warnings anyway FIXED - Configuration-as-Code plugin fails to export configurations on Java 10 ( JENKINS-51991) We anticipate to discover and report more issues during the hackathon this week. Contributing If you discover incompatibilities in plugins, please report issues in our bugtracker. We have java10 and java11 labels for such issues. If you are interested to try out Jenkins with Java 10 and 11 before June 22nd, you may be interested to sign-up to the Jenkins and Java 10+ online hackathon. Everybody is welcome to join, independently of their Jenkins experience and amount of time they have available. Exploratory testing is also within the hackathon’s scope. During this event, please also use the java10_hackathon label. It will help us to track contributions and send folks some small "thank you" gifts for participating (details will be figured out during the hackathon). If you want to contribute patches to the core, please submit pull requests to java10-support or java11-support branches. If the patches are compatible with Java 8, we will try to upstream them to weekly releases. For plugin patches please create pull requests against main branches and then follow guidelines from plugin maintainers. If you need additional reviews and you are a member of the jenkinsci organization, feel free to mention the @jenkinsci/java10-support team in your PRs. Links: Docker: jenkins/jenkins-experimental images JIRA: Java 10 compatibility JIRA: Java 11 compatibility Jenkins and Java 10+ online hackathon

On behalf of the Jenkins Events Team, I would like to invite you to the “Jenkins & Java 10 Online Hackathon” which will take place from June 18th to 22nd. We will be working together on Jenkins core and plugins in order to find and fix compatibility issues, share experiences and have some fun. Everybody is welcome to join, independently of their Jenkins experience and amount of time they have available. If you are interested in participating in the hackathon, please sign-up in this form. Background Java 9 has recently been end-of-lifed, Java 10 is in GA, and Java 11 is in early beta. Jenkins project currently requires Java 8 to run reliably, and there are some known compatibility issues with higher Java versions. During the Jenkins World 2017 Hackathon, Mark Waite and Baptiste Mathus spent some time exploring Java 9 compatibility in Jenkins. We are currently tracking compatibility issues in the JENKINS-40689 EPIC, but there are likely many unknown issues in Jenkins core, plugins and in libraries we use in the project. We would like to continue their effort and work on Java 10+ support. Objectives and Scope As I have said above, the goals are to explore/fix compatibility issues, share experiences and have fun. We DO NOT plan to make Jenkins fully compatible with Java 10+ during the hackathon, but we will try to integrate fixes and make them available. Since the announcement of the Hackathon in the mailing list, we have got a number of registrations from contributors working on several project areas. We will split our work to several areas: Jenkins core and Remoting Pipeline Engine Plugins (e.g. Git plugin or any plugin you want to work on) Exploratory testing for Java 10 and beyond In order to organize the effort, we have created a java10_hackathon label in Jenkins JIRA. If you are interested in particular tasks, please assign them to yourself and add the label. Organization Currently the event is in the planning stage. We will be using the Developer mailing list for synchronization before the event. What will we have? Communications in #jenkins-hackhouse IRC and in the Jenkins Gitter channel Daily recorded sync-up calls in Hangouts Knowledge transfer sessions during the event We also want to prepare some special swag for active participants. If you have reached this part of the blogpost, you have probably seen the logo ;) Links Registration Developer mailing list Hackathon sync-up document Running Jenkins with Java 10 and 11 JIRA: Java 10 compatibility JIRA: Java 11 compatibility JIRA: Hackathon tasks

On behalf of the Jenkins GSoC team and mentors, I would like to welcome Shenyu Zheng, Udara De Silva, Pham Vu Tuan and Abhishek Gautam. They will be working on Google Summer of Code projects in the Jenkins organization, and they have already done some contributions. This year we have the following projects: Code Coverage API Plugin - create a new API Plugin to unify existing Code Coverage plugins and provide new features. Student: Shenyu Zheng from Henan University, Kaifeng, China Mentors: Steven Christou and Supun Wanniarachchi Electronic Design Automation Plugins - create plugins for open-source Electronic Design Automation tools for synthesis, simulation and coverage analysis (iVerilog, covered, Yosys). Student: Udara De Silva from University of Akron, Ohio, USA Mentors: Martin d’Anjou and Oleg Nenashev Jenkins Remoting over Message Bus/Queue - add support of a popular message queue/bus technology (RabbitMQ or Kafka) as a fault-tolerant communication layer in Jenkins. Student: Pham Vu Tuan from Nanyang Technological University, Singapore Mentors: Oleg Nenashev and Supun Wanniarachchi Simple Pull-Request Job Plugin - add ability to define Jenkins jobs as YAML files stored in SCM, integrate it with existing plugin ecosystem. Student: Abhishek Gautam from Visvesvaraya National Institute of Technology, Nagpur, India Mentors: Jeff Knurek, Kristin Whetstone and Willy Aguirre During next 4 weeks project teams will be reaching out to potential stakeholders in order to establish connections and to get comments regarding their project designs. If you are interested in the projects, please join discussions in the Developer mailing lists and project meetings once they get scheduled. Please also expect expect more detailed blogposts about the projects soon. If you are interested to know more about GSoC in Jenkins, you can find information, timeline and communication channels here.

This is a post about a major change in Jenkins, which is available starting from Jenkins 2.102 and Jenkins LTS 2.107.1. This is a change with a serious risk of regressions in plugins. If you are a Jenkins administrator, please read this blogpost and upgrade guidelines BEFORE upgrading. I would like to provide some heads-up about the JEP-200 change, which is included into the new Jenkins LTS 2.107.x baseline. Background For many years Jenkins used to specifically blacklist certain classes and packages according to known or suspected exploits. This approach has been proven unsustainable due to the risk of deserialization attacks via unknown classes from 3rd-party components, after the SECURITY-429/CVE-2017-1000353 fix in 2.46.2 it was decided to replace blacklists by more restrictive whitelists. In October 2017 Jesse Glick proposed a Jenkins Enhancement Proposal, which finally got accepted as JEP-200. The change implies a risk of regressions in plugins serializing non-whitelisted Java-internal and 3rd-party classes, and that’s why it is so important to follow the upgrade guidelines for this release. Current state JEP-200 was first integrated in Jenkins 2.102 (released in January 2018), and it has got a lot of testing since that. See this blogpost for the original announcement. Over the last two months we received more than 75 issues from users of Jenkins weekly releases. All these issues have been triaged, and we have released most of the fixes. More than 50 plugins were fixed in total, and many more plugins were updated in order to enable compatibility testing. A significant part of the discovered regressions were caused by real defects which were causing performance and stability issues in plugins. Thanks a lot to all the Jenkins contributors and plugin maintainers who helped deliver timely changes for this effort! Over last 6 weeks Jenkins weekly releases had positive community ratings, the overall JEP-200 adoption reached ~12% of all Jenkins installations on March 01. All major plugins have been also tested directly or verified in the wild on weekly releases. So we are confident that the change is ready to be released in LTS. On the other hand, we continue to receive JEP-200 regression reports. They are mostly caused by niche plugins which are not widely used in weekly releases, and unfortunately not all fixes have been released yet (see the Wiki page for up-to-date info). We anticipate more regressions to be reported after the LTS release and broader adoption. In order to simplify the upgrade to the new LTS baseline, I have prepared some helpful materials together with Liam Newman and Jesse Glick. Below you can find the embedded slide deck and video, or scroll down to see the key information in the text form. Video: For Jenkins administrators Upgrading to a core with JEP-200 requires a special update procedure, which is described below. Upgrading Jenkins JEP-200 is not the only major change in 2.107.1, please read the full upgrade guide carefully If you have a way of testing the upgrade before applying it to production, do it Back up your instance so you have any easy way of rolling back Update all affected plugins. See this Wiki page for the list of affected plugins, fix statuses and workarounds Apply workarounds for non-released patches if needed (see below) Update to the new version of the Jenkins core Using backups and staging servers is good advice before any upgrade but especially this one, given the relatively high risk of regression. Due to the nature of the changes, some plugins may refuse to load after the upgrade and cause your Jenkins service to fail to start. After the upgrade To the extent that advance testing of the impact of this change on popular plugins has been completed, most users (and even plugin developers) should not notice any difference. Still, it is highly advised to monitor your system after the upgrade, especially the following: Jenkins System log (especially during the startup) Job/Build logs If you do encounter a log message referencing the https://jenkins.io/redirect/class-filter/ URL, most likely it is a JEP-200 regression. Example: some.pkg.and.ClassName in file:/var/lib/jenkins/plugins/some-plugin-name/WEB-INF/lib/some-library-1.2.jar might be dangerous, so rejecting; see https://jenkins.io/redirect/class-filter/ If you see this kind of message, we highly recommend reporting it so that it can be investigated and probably fixed quickly. Reporting JEP-200 issues Starting from May 01, JEP-200 issues are triaged by plugin and core maintainers. JEP-200 maintainers are available for code reviews if needed, but they will not be reviewing cases in JIRA and searching for miscategorized issues on a daily basis. If you experience new JEP-200 regressions, please follow the guidelines below. Please report any issues you encounter matching the above pattern in the Jenkins issue tracker, under the appropriate plugin component. Before reporting please check whether this issue has already been reported. Add the JEP-200 label Include the stacktrace you see in the log If possible, include complete steps to reproduce the problem from scratch You can find examples of previously reported issues using this query. Jenkins developers will evaluate issues and strive to offer a fix in the form of a core and/or plugin update. Right after the feature release there was be a special team triaging the reports. Starting from May 01 the issues will be triaged by plugin and core maintainers. See JEP-200 Maintenance plan for more info. For more details and current status, see Plugins affected by fix for JEP-200. Applying workarounds Assuming you see no particular reason to think that the class in question has dangerous deserialization semantics, which is rare, it is possible to work around the problem in your own installation as a temporary expedient. Note the class name(s) mentioned in the JEP-200 log messages, and run Jenkins with the hudson.remoting.ClassFilter startup option, e.g.: java -Dhudson.remoting.ClassFilter=some.pkg.and.ClassName,some.pkg.and.OtherClassName -jar jenkins.war ... This workaround process may require several iterations, because classes whitelisted in the workaround may also include fields with types requiring whitelisting. For plugin developers If you are a plugin developer, please see the original JEP-200 announcement. That blog post provides guidelines for testing and fixing plugin compatibility after the JEP-200 changes. The presentation above also provides some information about what needs to be tested.