Jira upgrade for the Jenkins project

October 17, 2021, 5:42 am

≫ Next: Google Summer of Code 2020 summary

≪ Previous: Google Summer of Code 2021 call for Project Ideas and Mentors

$

0

0

The Jenkins project has used Jira to track issues for many years. Jenkins core, Jenkins modules, Jenkins infrastructure, and many Jenkins plugins manage their issue reports with our Jira server.

Jira helps the Jenkins project manage issues and tasks related to over 250 000 Jenkins installations. It tracks bugs, enhancement requests, tasks, and security issues. It is used regularly by users around the world.

We’re grateful for the long-standing contribution that Atlassian provides by donating the Jira license to the Jenkins project. We’re grateful to the Oregon State University Open Source Lab for their donation of equipment and bandwidth to host the server.

Upgrade Timeline

We were running Jira 7.13 and had been managing that installation for a few years. Atlassian announced that Jira 7.13 would end its support life on November 28, 2020. We needed to upgrade from Jira 7.13 to a more recent version of Jira. As part of our membership in the Continuous Delivery Foundation, a Linux Foundation initiative, we could use their project services team to manage our Jira server. We decided to move from hosting our own Jira server to having the Jira experts at the Linux Foundation host it.

The upgrade timeline looked like this:

• November 2019 - Infrastructure team begins discussions about the November 2020 end of support for Jira 7.13

• August 2020 - First conversations with Linux Foundation to host Jira for the Jenkins project. Draft of the upgrade plan assembled and shared with the community

• September 2020 - Schedule for testing week and final transition week proposed. Authentication options evaluated and selected

• October 2020 - Test upgrade performed and tested

• November 2020 - Final upgrade completed and verified

Confronting the Complications

Initial discussions between the Jenkins infrastructure team and the Linux Foundation identified complications related to authentication and SSL certificates. We planned, negotiated, and tested our assumptions throughout the project.

Authentication

Jira servers at the Linux Foundation typically use Linux Foundation accounts for user access. Unfortunately, the Jenkins LDAP database includes over 100,000 users and for many of them, Linux Foundation username doesn’t correspond to Jenkins account username. It was not feasible to transition 100,000 user accounts from the Jenkins LDAP database to the Linux Foundation accounts system and still complete the Jira upgrade before the November 28, 2020 deadline.

The Linux Foundation Project Services team evaluated authentication alternatives and confirmed that they could use the Jenkins LDAP server. Using the Jenkins LDAP server spared us from two transitions, LDAP and Jira, and kept the project timeline feasible.

SSL Certificates

Jira servers at the Linux Foundation use Let’s Encrypt to generate SSL certificates for HTTPS. The Linux Foundation uses the DNS method to obtain SSL certificates. Unfortunately, the Jenkins project uses the HTTP method to obtain SSL certificates.

Thankfully, Olivier Vernin of the Jenkins project and Anton Baranov of the Linux Foundation found a solution. They created an ACME record in the Jenkins DNS server and pointed the issues.jenkins.io DNS record at the new Linux Foundation Jira server.

Building the Prototype

Anton Baranov created a prototype Jira server, restored an older Jenkins Jira backup, and upgraded it to Jira 8.13. That first restore detected that we had not provided the Jira attachments or the Jira avatars. That attachments and avatars added multiple gigabytes to the initial backup data and were vital to complete the update.

Testing the Upgrade

A group of volunteers including Jenkins users, security team members, and infrastructure team members tested the upgrade during the week of October 26, 2020. The tests confirmed that authentication worked as expected and that the Jira prototype was functioning as expected.

We thank the test team, including:

• Daniel Beck

• Tim Jacomb

• Olivier Vernin

• Mark Waite

The tests included:

• Creating and routing issues

• Commenting on issues

• Viewing dashboards with the expected content

• LDAP settings

• Email notification

The tests detected minor issues that Anton was able to correct in preparation for the final upgrade. The testing team agreed that the tests were successful.

Deploying the Upgrade

Olivier Vernin announced the final upgrade by email to the Jenkins infra list with details of the changes happening during the upgrade. Monday, November 9, 2020, the final backup of the existing Jira server was copied into the new Linux Foundation server.

The final upgrade encountered issues that we had not seen during the initial tests. The "bumps and bruises" from the unexpected issues were resolved by Anton Baranov as he used a multi-step upgrade process. The steps included:

• Restore the earlier backup to Jira 7.13

• Restore the most recent backup

• Upgrade to Jira 8.13

• Install avatars, attachments, and other images

• Update DNS entries to point to the new Jenkins Jira server

Lessons from the Upgrade

Lessons were related to timing, estimation, and communication.

Scheduling the Upgrade

The test upgrade started the week of October 19, 2020. It took several days longer than originally expected. Thankfully, we had allowed an extra week between the test upgrade and the production upgrade.

The originally announced schedule for the final upgrade was intentionally placed in a week that would not include a long term support release. That reduced the risk of disruption if the upgrade took longer than required or failed and we had to roll back.

Estimating the Work

Discussions with the Jenkins project Jira administrators and the Linux Foundation Jira experts provided very reasonable estimates of time to complete the work. We intentionally allowed additional time between first test and final upgrade. We needed that additional time and used it well as the testing week.

Communicating the Plan

The distributed nature of the Jenkins project makes communication challenging for major changes. We communicated plans at various stages but still found occasions where the communication was insufficient. In this case, the adage held true that it is, "impossible to communicate too much".

Thanks for your patience during the upgrade and thanks to the Linux Foundation for administering the Jenkins Jira server.

---

Google Summer of Code 2020 summary

October 17, 2021, 5:42 am

≫ Next: 2020 A Year Like No Other

≪ Previous: Jira upgrade for the Jenkins project

$

0

0

With the mentor summit and the project retrospectives finished in October, now we can call Google Summer of Code 2020 officially over in the Jenkins community. On behalf of the Jenkins org team, we would like to thank all participants: students, mentors, applicants, and dozens of other contributors who participated in the project this year. Google Summer of Code would not be successful without the active participation of the Jenkins community.

If you follow the Jenkins blog, you may have already seen many GSoC 2020 articles created by the project teams. Here I would like to focus on the key highlights from the project.

Projects

In 2020 we had seven students working in the Jenkins mentoring organization. We had 6 projects focused on Jenkins and one project focused on Jenkins X. As usual, in GSoC we focused on problems important to the Jenkins users and community members. The projects delivered highly anticipated new features and key architecture changes needed for long-term evolution of Jenkins.

Here are the projects we had this year:

• Custom Jenkins distribution build service by Sladyn Nunes

• External Fingerprint Storage by Sumit Sarin

• Git Plugin Performance Improvements by Rishabh Budhouliya

• GitHub Checks API for Jenkins Plugins by Kezhi Xiong

• Jenkins X: Apps/Addons consolidation by Zixuan Liu

• Machine Learning Plugins for Data Science by Loghi Perinpanayagam

• Jenkins Windows Services: YAML Configuration Support by Buddhika Chathuranga

Please refer to the project pages for more information, links to the blog posts, and project demos. Let’s focus on the results instead. This is the first ever time in Jenkins when all GSoC students have reached the final evaluation and successfully passed it. It was an incredible effort by all the project members and, most importantly, by the students. Thanks a lot to them!

.

Thanks a lot to all mentors who were guiding students during their projects:Zhao Xiaojie,Kristin Whetstone,Parichay Barpanda,Martin d’Anjou,Oleg Nenashev,Andrey Falko,Mike Cirioli,Mark Waite,Francisco Fernandez,Justin Harringa,Omkar Deshpande,Ulli Hafner,Tim Jacomb,Kara de la Marck,James Strachan,Neha Gupta,Oscar Medina,Nikhil Da Rocha,Sahil Kalra,Bruno P. Kinoshita,Ioannis Moutsatsos,Marky Jackson,Shivay Lamba, andNext Turn.

GSoC 2020 Org admin team:Kara de la Marck,Martin d’Anjou,Marky Jackson,Oleg Nenashev.

Events

Thanks to the GSoC organization stipend from Google and other donations, the Jenkins project usually provides travel grants to successful students so that they can visit a major community event, meet their mentors and community members in person, and present their work there. Here are some notes about the GSoC 2019 travel. Unfortunately this year it was not possible, and GSoC went completely virtual this year.

Online meetups

In August we organized Jenkins Online Meetups where students have presented their projects (part 1, part 2). You can find recordings of these presentations in this playlist on the Jenkins YouTube channel.

DevOps World

This year CloudBees, one of the Jenkins corporate sponsors, invited all students to participate in the DevOps World virtual conference on September 23-25. GSoC students did lighting talks about their projects, attended other conference talks, and joined the Continuous Delivery Foundation booth which represented the project at the conference. You can find recordings of the talks and all materials here. Although the conference was in September, the talks were pre-recorded in early August. Please refer to the Jenkins online meetup recordings for the recent versions.

GSoC Mentor summit

This is a regular gathering for Google Summer of Code mentors and org admins where they share their experiences about GSoC, outreach programs, community management, and tools. Usually it is organized as a multi-day unconference after the end of GSoC, with 2-3 representatives from each project. It has been a great learning experience to participate in it. This year it was a single-day virtual event, and all mentors were able to attend.Shivay Lamba, one of the GSoC 2020 mentors, also did a lightning talk about the GSoC projects he was working on in Jenkins and CNCF (slides).

Swag

All Google Summer of Code students and mentors get swag from Google. This year, Contrinuos Delivery Foundation (CDF) has sponsored swag for 50 most active GSoC participants: all students, mentors, and many other contributors who participated and helped the projects to succeed. This is the third year when the Jenkins organization sends extra GSoC swag, In the previous years the swag logistics was one of the most challenging tasks for org admins during the entire project. and we highly appreciate help from CDF with this part. As DevOps World presenters, the students have also received special edition speaker swag from CloudBees.

Thanks a lot to Google, Contrinuos Delivery Foundation (CDF) and CloudBees!

Retrospective

After completion of the coding phases, org admins have reached out to all GSoC 2020 participants to gather their feedback and suggestions. We also recommended that project teams hold their own retrospective meetings. Such information is instrumental to continuously improving GSoC in the Jenkins community. We thank all contributors who shared their feedback!

The organization-wide retrospective was organized as a survey and a series of retrospective meetings. You can find aggregated results in this Google Doc. Overall, we received very positive feedback from students and mentors. The GSoC framework in Jenkins has matured significantly during the previous years. The effort we invested to create guidelines and recommendations for all parties helped a lot because all the expectations were known in advance. As usual, there is much to improve, especially with regards to the community bonding phases and cross-project communications. We are processing the feedback, and we will expand our documentation and the contributor onboarding plans next year.

Some personal notes

I have been involved in leading and coordinating Google Summer of Code in open source projects since 2016. This year I visited the GSoC stand at FOSDEM and met a few organizers and former students. A few days after, I proposed participating in GSoC at the Jenkins contributor summit in Brussels, and several contributors supported this idea. We spent several hours to create the first Jenkins GSoC page and brainstorm on project ideas. We submitted our application and were accepted. Thanks a lot to the Google team that gave us a chance!

It is great to work with the students and see how they explore the open source community and grow professionally as engineers. It is also awesome to see how some of them stay in the project and keep contributing, including becoming plugin maintainers and GSoC mentors. But, for me, Google Summer of Code is not just about mentoring. It also helps a lot with the community bonding…​ for the existing community like Jenkins which has a lot of isolated sub-communities in plugins. Many maintainers work alone, and it can be quite lonely working to maintain a plugin without feedback, developer ideas, and user interactions. When plugin contributors become project mentors, they join the wider community effort and work in teams. In many cases they start contributing to the organization-wide activities and goals, and it grows the "backbone" of the Jenkins community. Like other community-driven projects, we need such backbone to scale the community and onboard more contributors to the countless Jenkins components. So far it works really well and GSoC excels among outreach programs in this regard.

I would like to thank the Google Open Source team, students and all Jenkins community members for the great Google Summer of Code this year. We also thank the Continuous Delivery Foundation for their help to recognize contributors and allow organization administrators to focus on projects. Last but not least, I would like to thank the Jenkins org admin team:Martin d’Anjou,Marky Jackson, andKara de la Marck. This was a crazy year for everyone. Regardless of that, the org admins stepped up and took responsibility for students and mentors involved in the project, with a serious time commitment. Not all work by the organizers is publicly visible (applications, project selection, resolving conflicts), but this work is essential to the project’s success. Thanks a lot to org admins and mentors who helped with the administrative tasks this year!

What’s about GSoC 2021?

Yes, we plan to participate in Google Summer of Code 2021. The application period for organizations will start in a few months, but we have already started preparing for the next GSoC session. We are looking for mentors, org admins and project ideas. Please contact us if you are interested!

• Call for Mentors and Project Ideas

• GSoC 2021 project ideas

• HOWTO: Propose a project idea

• Information for mentors: guidelines and expectations

We invite potential students to start exploring the project and the available project ideas. Original ideas are always welcome in the project, and starting early is a great opportunity to get introduced to the Jenkins community, collect more information about the problem areas, and to create a good proposal. "Start early" is the most popular recommendation from GSoC 2020 participants to future GSoC students, and we encourage you to follow this advice!

2020 A Year Like No Other

October 17, 2021, 5:42 am

≫ Next: New eBook: Build, deploy, and automate great stuff with Jenkins

≪ Previous: Google Summer of Code 2020 summary

$

0

0

The Jenkins community congratulates all users and contributors with the New Year! Let’s take a look at some changes this year. We would like to thank all awesome Jenkins users and contributors who have been with us during this year.

Highlights

Some of the key highlights:

• Hundreds of first-timer contributors joined the community

• Major UI/UX improvements in the Jenkins core, including the landing page, plugin manager, dark theme, and read-only configurations support

• Outreach programs like Google Summer of Code (7 projects), Google Season of Docs, UI/UX hackfest, etc.

• Public roadmap for the project

• Terminology changes in the project, new Code of Conduct

• Technical debt cleanup: XStream unforking, Acegi Security replacement, etc.

• Continued evolution of the plugin ecosystem, especially in the area of Cloud Native solutions and tool integrations

• Continued documentation cleanup, great progress with plugin documentation migration

• Graduation in the Continuous Delivery Foundation

Jenkins User Interface and User Experience

This year there were many activities around Jenkins user experience and long-anticipated user interface changes. This is a coordinated effort being led by the User Experience SIG, and by many contributors to the project. Key project highlights:

• Look & Feel updates of the Jenkins Web UI, including styling rework, new typography and layouts

• Major rework of plugin management UI/UX

• Dark theme for Jenkins

• Accessibility improvements

• Support for read-only configuration pages

In May we also organized a Jenkins UI/UX hackfest where we worked on some key stories improving user experience.

Jenkins security

In 2020 the Jenkins security team has released 19 advisories for the Jenkins core, plugins and other components. In total 198 vulnerabilities were fixed, and 72 plugin vulnerabilities were announced without a fix at the time of advisory publishing. As a project, we are receiving a continuous flow of new reports and continue to provide corrections. Cross-site scripting (XSS) vulnerabilities were the most popular type this year, followed by unprotected credentials.

There have also been developer tooling improvements, including GitHub CodeQL evaluation for targeted security issues search and Find-Sec-Bugs adoption for static analysis of the plugin and Jenkins core code. Along with wider adoption of Dependabot and automated dependency scanning on GitHub.

Documentation

Jenkins Documentation SIG is working on creating more documentation for Jenkins on different platforms, including cloud platforms. Jenkins on Kubernetes was one of the key stories this year for the SIG, along with documentation migration to jenkins.io and wider adoption of Documentation-as-code in plugins. 95% of the 200 most installed Jenkins plugins have moved to "documentation as code" or have a pending pull request with updates. In total, almost 600 plugins have already been migrated. There were major updates in Jenkins documentation on jenkins.io, with a lot of content being moved from the old Jenkins Wiki.

2020 was the first year when Jenkins participated in Google Season of Docs (GSoD). This program brings together open-source and technical writers communities for the benefit of both. This year’s student, Zainab Abubakar, did an amazing job documenting Jenkins on Kubernetes. Now Jenkins users can find official documentation about deploying and scaling Jenkins in Kubernetes. See the project report by Zainab here.

Jenkins Release Automation

The Jenkins project has delivered weekly and long term support releases since it was formed in 2011. Those releases were delivered by Kohsuke Kawaguchi from his release infrastructure.

Beginning in April 2020, those releases are delivered by the new release automation setup. It is hosted within the Jenkins’ Kubernetes cluster, with fully automated management and continuous delivery of services within the setup. We transitioned to new build processes, new code signing certificates, and new release automation jobs. Thanks to Olivier Vernin and all Infrastructure sub-project contributors for the successful completion of the release automation project!

Moreover, there is ongoing work on continuous delivery of Jenkins plugins (JEP-229) and on re-designing other Jenkins instances within the project (infra-ci, trusted-ci, and ci.jenkins.io for plugins). In the next few months these stories should provide Jenkins contributors with a modern environment for CI and CD of all Jenkins components.

Terminology updates

Since July, we have officially replaced the old "master" terminology with the "controller" term. It is a follow-up to the "agent" terminology introduced in 2016. We have also deprecated usages of the “blacklist/whitelist” terminology in all components. Currently the community is working on the cleanup of the remaining occurrences in the codebase and documentation, and we invite everyone to contribute.

As a part of the terminology cleanup, last spring we announced the renaming of the official Docker images for Jenkins agents. As a reminder, it does not have any immediate impact on Jenkins users, but they are expected to gradually upgrade their instances.

See more information about terminology updates here and here.

“Jenkins is the Way” program

This year the Advocacy and Outreach SIG started the “Jenkins is the Way” initiative which focuses on promoting user success stories. Over the year, the team published 54 user stories and six case studies on https://jenkinsistheway.io/ as well as a significant amount of community marketing. We also published a number of testimonial videos advertising user stories, including this Introduction to "Jenkins is the Way" video.

See all the stories HERE

Events

Google Summer of Code

In 2020 we had seven students working in the Jenkins mentoring organization. We had 6 projects focused on Jenkins and one project focused on Jenkins X. As usual, in GSoC we focused on problems important to the Jenkins users and community members. The projects delivered highly anticipated new features and key architecture changes needed for the long-term evolution of Jenkins.

This is the first-ever time in Jenkins when all GSoC students have reached the final evaluation and successfully passed it. It was an incredible effort by all the project members and, most importantly, by the students. Thanks a lot to them!

Read more: https://www.jenkins.io/blog/2020/12/22/gsoc-report/

Jenkins in Hacktoberfest 2020

In October we participated in Hacktoberfest. Our featured projects included the Jenkins core, jenkins.io website and plugins.jenkins.io, Helm charts, and multiple plugins. We also encouraged contributors to participate in the Documentation as Code and terminology cleanup across the entire Jenkins ecosystem.

See the details in the Hacktoberfest page.

In total we received 226 pull requests from Hacktoberfest participants. Some stats per Jenkins GitHub organization:

• 'jenkinsci', PRs: 189, Hacktoberfest contributors: 61

• 'jenkins-infra', PRs: 100, Hacktoberfest contributors: 40

• 'jenkins-zh', PRs: 37, Hacktoberfest contributors: 2

Jenkins at DevOps World

The annual DevOps World, formerly known as DevOps World | Jenkins World held on Sept 22-24, with workshops on Sept 25. Just like other events in 2020, DevOps World pivoted to a virtual event but that didn’t mean there was a shortage of sessions or networking opportunities. There were over 50 Jenkins/open-source. And a special congratulations is in order to this year’s Jenkins Contributor Award winners:

• James Holderness - Jenkins security MVP

• Marky Jackson - Most valuable Jenkins advocate

• Tim Jacomb - Most valuable Jenkins contributor

Below are just a few sessions, the full agenda can be found HERE:

• Jenkins Where It Is and Where It Is Going

• One Jenkins to Rule them All

• Jenkins UI Gets a Makeover

• Jenkins Pipeline and DevSecOps for API Security

Graduation at Continuous Delivery Foundation

Jenkins is the first project to graduate in the CD Foundation. In August the project announced that the Jenkins project has achieved the graduated status in the Continuous Delivery Foundation (CDF). Thanks to all contributors who made our graduation possible! Below you can find a few key changes we have applied during the graduation process:

• We introduced a new public roadmap for the Jenkins project. This roadmap aggregates key initiatives in all community areas: features, infrastructure, documentation, community, etc. It makes the project more transparent to all Jenkins users and adopters, and at the same time helps potential contributors find the hot areas and opportunities for contribution. The roadmap is driven by the Jenkins community and it has a fully public process documented in JEP-14.

• A new list of Jenkins adopters was introduced on jenkins.io. This list highlights Jenkins users and references their case studies and success stories, including ones submitted through the Jenkins Is The Way portal. Please do not hesitate to add your company there!

• We passed the Core Infrastructure Initiative (CII) certification. This certification helps us to verify compliance with open source best practices and to make adjustments in the project (see the bullets below). It also provides Jenkins users and adopters with a public summary about compliance with each best practice. Details are on the Jenkins core page.

• Jenkins Code of Conduct was updated to the new version of Contributor Covenant. In particular, it sets best practices of behavior in the community, and expands definitions of unacceptable behavior.

More information can be found HERE, and HERE.

Public Roadmap

The Jenkins project now has a public, community-driven project roadmap. Roadmap items are major initiatives and are considered as official plans. The roadmap aggregates key initiatives in all areas of the project.

Many of the 2020 released roadmap items are mentioned elsewhere in this document, including release automation, Core Infrastructure Initiative (CII) certification, user interface improvements, read-only configuration pages, and Google Summer of Code projects like the GitHub Checks API or External Fingerprint Storage.

Other roadmap items include mirror infrastructure improvements, a new Windows installer, and preview releases of pluggable storage for external fingerprints, build logs, and unit test results.

Jenkins 2020 Elections

In October-December the Jenkins community held the regular elections. This year we were electing for 2 governance board members and for all five officer positions, namely: Security, Events, Release, Infrastructure, and Documentation. These roles are an essential part of Jenkins' community governance and well-being. We thank all candidates and voters who participated this year.

Key results:

• Gavin Mogan and Marky Jackson joined the Jenkins Governance Board

• Tim Jacomb was elected as Release Officer

• Marky Jackson became the new Events Officer

• Olivier Vernin, Daniel Beck, and Mark Waite will continue as Infrastructure, Security and Documentation officers

Full election results: https://www.jenkins.io/blog/2020/12/03/election-results/

And even more

This blog post does not provide a full overview of what changed in the project, it is just a slice of the key highlights mentioned by the contributors. The Jenkins project consists of more than 2000 plugins and components which are developed by thousands of contributors. Thanks to them, a lot of changes happen in the project every day. We are cordially grateful to everybody who participates in the project, regardless of contribution size. Everything matters: new features, bug fixes, documentation, blog posts, well reported issues, Stackoverflow responses, etc. THANKS A LOT TO ALL CONTRIBUTORS!

So, keep updating Jenkins and exploring new features. And stay tuned, there is much more to come next year!

What’s next?

Technical changes. 2021 will be another busy year for the Jenkins community. There are many long-overdue changes in the project, which need to happen if we want Jenkins to succeed. There are many areas on the roadmap: UX revamp, cloud native Jenkins, pluggable storage, etc. There will also be a continued cleanup of old dependencies and technical debt. Several key changes are expected to land in the March LTS baseline: update to Spring Security, XStream unforking, JQuery update, etc.(announcement). In addition to that, we will keep working on expanding platform support in Jenkins, including provisioning support for new Java versions and official images for more architectures like Arm.

Documentation. Documentation efforts will continue in the next year, with a focus on documenting Jenkins usage on modern platforms and and automation use-cases. Wide adoption of documentation-as-code will also continue for plugins By this time almost 600 plugins have been migrated, but there are hundreds more plugins to go.

Security. Another important area is Jenkins security. Automation tools like Jenkins are a key part of the software delivery process in organizations, and their security is essential for the security of products. Misconfigured or outdated systems are a common attack vector, but there are also areas for improvement on the project’s side. Be sure there will be security advisories and vulnerability fixes in 2021. We plan to keep adopting best security development and software delivery practices, and to improve dependency management and developer tools in the project. These areas will be in the spotlight for the project next year.

Events. Next month we will participate in FOSDEM, and there will be a virtual Jenkins stand there. There will also be a CI/CD devroom. If you are interested to meet Jenkins contributors, it is a great opportunity. We also plan to continue all outreach programs and on onboarding more contributors. At the moment we are looking for Google Summer of Code 2020 mentors and project ideas (announcement). We are also ready to consider other non-coding project ideas as a part of CommunityBridge. If you are interested, please contact the Advocacy and Outreach SIG.

Join us in 2021!

We are always looking for more contributors, regardless of the profile and experience. Jenkins is a vast ecosystem which includes many modern technologies.

We invite Jenkins users and contributors to participate in the community and to move these initiatives forward! Join us in the mailing lists and special interest groups,

New eBook: Build, deploy, and automate great stuff with Jenkins

October 17, 2021, 5:42 am

≫ Next: Docker image updates

≪ Previous: 2020 A Year Like No Other

$

0

0

In April of last year, we launched a new Jenkins community website called JenkinsIsTheWay. The Jenkins Is The Way site has collected the experiences of Jenkins users around the world as they develop software and create solutions. They are charting new paths, discovering new opportunities, and overcoming challenges.

That’s what makes Jenkins Is The Way tick. Engineers in the Netherlands might have already met challenges faced by developers in India. Solutions uncovered by DevOps teams in Spain may benefit those just starting in the USA. Interns in Bogota may develop pipeline solutions that can be integrated into workflows used across the globe in Tokyo. Or vice versa!

No matter where you are, regardless of whether your solution is regional or global in nature, Jenkins Is The Way.

Telling your stories in a new eBook

To date, we have nearly 60 user stories, a handful of case studies, and some new user testimonial videos from the Jenkins community. You shared how using Jenkins has helped make your builds faster, your pipelines more secure, and your developers and software engineers happier. In essence, Jenkins Is The Way showcases how Jenkins has made it a whole lot easier to do the work you do every day.

We’ve now gathered some of those stories in our first Jenkins Is The Way ebook, covering various challenges and solutions from six different industries: Aerospace, Education, Finance, Insurance, Retail, and Travel.

You’ll read about innovations from KP Labs in Poland and Preply in Ukraine. You’ll discover how automation helped Avoris out of Spain & Portugal and Tymit in the United Kingdom. And you’ll be inspired by what China’s JD.com and Topdanmark in Denmark were able to achieve after tapping into the Jenkins community.

This curated collection of stories illustrates how Jenkins community members build next-generation DevOps and CI/CD platforms as the backbone for software innovation across companies of all sizes. They highlight the innovation, ingenuity, and keen ability to adapt Jenkins plugins to handle everyday business issues, everywhere.

The technology landscape is full of solutions perfected to tackle all aspects of software development. But time and time again, developers keep coming back to Jenkins. Your engineering time and resources are too valuable to be spent re-inventing the wheel or handling manual testing and deployment cycles.

Jenkins' vast array of plugins and pre-built solutions will have you automating more than you ever imagined. So, get inspired to build great stuff with Jenkins. And, please share this ebook with your network.

Share your story!

And when you’re ready to tell your story, we’re prepared to help you share it. Fill out the short questionnaire, and we’ll send you our Jenkins Is The Way T-shirt as a thank you!

Special thanks to CloudBees, Inc. for sponsoring this program.

Docker image updates

October 17, 2021, 5:42 am

≫ Next: Jenkins Contributor Summit Online Feb 23-25

≪ Previous: New eBook: Build, deploy, and automate great stuff with Jenkins

$

0

0

Beginning with Jenkins 2.279 and Jenkins 2.263.4, the Jenkins project is upgrading the base operating system and Java version used in the jenkins/jenkins:latest and jenkins/jenkins:lts images. The update replaces OpenJDK 8u242 with AdoptOpenJDK 8u282 and replaces Debian 9 ("Stretch") with Debian 10 ("Buster").

Why?

We’re changing the base image so that we have a better supported operating system and a more current Java release for Jenkins controllers.

Better supported operating system

The Docker images provided by the Jenkins project rely on the operating system security processes of the operating system provider.

Our Docker images have used Debian 9 ("Stretch") for multiple years. Debian 9 security updates have been discontinued as of July 6, 2020. Debian 9 Long Term Support security updates will be discontinued at the end of June 2022. The upgrade to Debian 10 keeps us on an operating system maintained by the operating system security team.

More current Java release

The Debian 9 Docker images were based on the openjdk:8-jdk-stretch Docker image. The last update to that image was one year ago with the release of JDK 8u242. We need a maintained Docker base image that keeps pace with JDK releases and operating system updates so that the controller is running the most recent Java updates and most recent operating system updates.

Other Jenkins controller images have already switched from using openjdk base images to instead use base images provided by Eclipse Adoptium.Eclipse Adoptium is the Eclipse project formed when AdoptOpenJDK joined the Eclipse Foundation. This change adapts the jenkins/jenkins:latest and jenkins/jenkins:lts images to use the Adoptium JDK images in the same pattern as is already used for the Jenkins JDK 11 Docker images like jenkins/jenkins:lts-jdk11. The Jenkins Platform SIG has enjoyed very good results in our interactions with the Eclipse Adoptium project. We look forward to continuing our collaboration with them.

Thanks a lot to Alex Earl and Jim Crowley for the image build restructuring groundwork that made the image upgrade possible! Also thanks to Oleg Nenashev and other contributors for their reviews and testing.

Packaging changes

The Jenkins Docker image based on Debian 10 ("Buster") includes some different packages than Debian 9 ("Stretch"). Some packages have been removed because they are no longer supported by their communities. Some packages have been removed due to infrequent and decreasing use. Users of the Jenkins Docker images may need to extend their definition of their Docker image to include packages that are no longer included in the base image.

SCM packages removed

The following source control management packages are no longer included in the Jenkins controller images for jenkins/jenkins:latest or for jenkins/jenkins:lts:

• bzr

• mercurial

• subversion

Other packages removed

Additional packages that are no longer included in the Jenkins controller images include:

• bzip2

• mime-support

• python (the Python project stopped supporting Python 2 January 1, 2020)

• xz-utils

A detailed list of the exact package changes is available in the pull request.

Upgrade and compatibility notes

The Jenkins controller images are designed to be extended to meet user needs. Custom Jenkins controller images can be created from the base images and are designed to allow additional Jenkins plugins and additional operating system packages.

For example, the Installing Docker instructions illustrate a technique to install the Blue Ocean plugins and some operating system packages in a custom Docker image.

Docker image with Subversion

The following Docker image definition installs the most recent Jenkins Long Term Support release with the subversion plugin and the operating system subversion command:

FROM jenkins/jenkins:lts
USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends subversion
USER jenkins
RUN jenkins-plugin-cli --plugins subversion:2.14.0

Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-subversion:1.1":

docker build -t myjenkins-subversion:1.1 .

Docker image with Mercurial

The following Docker image definition installs the most recent Jenkins Weekly release with the mercurial plugin and the operating system hg command:

FROM jenkins/jenkins:latest
USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends mercurial
USER jenkins
RUN jenkins-plugin-cli --plugins mercurial:2.12

Build a new docker image from this Dockerfile and assign the image a meaningful name, e.g. "myjenkins-mercurial:1.1":

docker build -t myjenkins-mercurial:1.1 .

What’s next?

We will continue Docker image updates as new Java versions are released.

If you are interested in new features in Jenkins Docker packaging, stay tuned for future announcements! There are multiple ongoing initiatives which you can find on the public Jenkins roadmap. Some stories:

• Switching to AdoptOpenJDK.

• General availability of Windows images.

• Support for more platforms (AArch64, IBM s390x, PowerPC).

• Introducing multi-platform Docker images.

If you are interested in any of these projects and would like to contribute, please reach out to the Platform Special Interest Group which coordinates initiatives related to Jenkins in Docker.

Jenkins Contributor Summit Online Feb 23-25

October 17, 2021, 5:42 am

≫ Next: cdCon 2021 - Call for Jenkins Proposals

≪ Previous: Docker image updates

$

0

0

The Jenkins Contributor Summit brings together current and future contributors to the Jenkins project. We’re hosting an online summit this year to encourage contributors from around the world to meet, discuss, and plan for the future.

The Contributor Summit will be Tuesday, February 23rd 2021 through Thursday, February 25, 2021. The summit brings together community members to learn, meet, and help shape the future of Jenkins. In the Jenkins community we value all types and sizes of contributions and love to welcome new participants.

Format

The online format allows greater flexibility for meeting times and topics. Contributors will meet to discuss specific topics in smaller groups at times that are convenient for those in the meeting.

Opening session

The opening session will start Tuesday, February 23, 2021 at 15:00 UTC. After an initial welcome and overview, we’ll hear from leaders in the Jenkins project as they share the results from the previous 12 months and outline ideas for the next 12 months.

• Security - Daniel Beck

• Infrastructure - Olivier Vernin

• Release - Tim Jacomb

• User experience - Félix Queiruga

• Chinese localization - 赵晓杰(Rick)

• Configuration as code - Tim Jacomb

• Google Summer of Code - Kara de la Marck

• Documentation - Mark Waite

• Events and Advocacy - Alyssa Tong

• Cloud Native - Kara de la Marck

• Platforms - Mark Waite

After those presentations, we’ll create "breakout rooms" in the online meeting that will allow those interested in specific tracks to meet, identify preferred times for their tracks, and prepare draft agendas for their tracks.

Tracks

Smaller sessions ("tracks") will be run in the 48 hour period between the opening session and the closing session. These smaller sessions will be focused on specific topics. A track leader will organize the track meeting, facilitate discussions in the track meeting, and present a summary of the track results in the closing session.

Closing session

The opening session will start Thursday, February 25, 2021 at 15:00 UTC. After an initial welcome and overview, we’ll hear from track leaders as they share the results from their track meetings.

We’ll identify items that should be added to the Jenkins roadmap, items that should be further investigated by special interest groups, and items that need further discussion elsewhere.

cdCon 2021 - Call for Jenkins Proposals

October 17, 2021, 5:42 am

≫ Next: Update-Center certificate rotation

≪ Previous: Jenkins Contributor Summit Online Feb 23-25

$

0

0

Hear ye! Hear ye! Jenkins Community,

cdCon 2021 (the Continuous Delivery Foundation’s annual flagship event) is happening June 23-24 and its call for papers is open!

This is your chance to share what you’ve been doing with Jenkins. Are you building something cool? Using it to solve real-world problems? Are you making things fast? Secure? Or maybe you’re a contributor and want to share what’s new. In all cases, we want to hear from you!

Submit your talk for cdCon 2021 to be part of the conversation driving the future of software delivery for technology teams, enterprise leadership, and open-source communities.

Submission Deadlines

Early-Bird Deadline

Friday, February 19 by 11:59 PM PST

Final Deadline

Friday, March 5 at 11:59 PM PST

Topics

Here are the suggested tracks:

Continuous Delivery Ecosystem

This track spans the entire Continuous Delivery ecosystem, from workflow orchestration, configuration management, testing, security, release automation, deployment strategies, developer experience, and more.

Advanced Delivery Techniques

For talks on the very cutting edge of continuous delivery and emerging technology, for example, progressive delivery, observability, and MLOps.

GitOps & Cloud-Native CD

Submit to this track for talks related to continuous delivery involving containers, Kubernetes, and cloud*native technologies. This includes GitOps, cloud-native CD pipelines, chatops, best practices, etc.

Continuous Delivery in Action

This track is for showcasing real-world continuous delivery addressing challenges in specific domains e.g. fintech, embedded, healthcare, retail, etc. Talks may cover topics such as governance, compliance, security, etc.

Leadership Track

Talks for leaders and decision-makers on topics such as measuring DevOps, build vs buy, scaling, culture, security, FinOps, and developer productivity.

Community Track

There is more to open source than code contributions. This track covers topics such as growing open source project communities, diversity & inclusion, measuring community health, project roadmaps, and any other topic around sustaining open source and open source communities.

Singular project focus and/or interoperability between:

• Jenkins

• Jenkins X

• Ortelius

• Spinnaker

• Screwdriver

• Tekton

• Other – e.g. Keptn, Flagger, Argo, Flux

View all tracks and read CFP details.

We look forward to reading your proposal!

Submit it here

Update-Center certificate rotation

October 17, 2021, 5:42 am

≫ Next: Jenkins accepted in Google Summer Of Code 2021!

≪ Previous: cdCon 2021 - Call for Jenkins Proposals

$

0

0

On the 29th of March 2021, we’ll rotate the Jenkins update center certificate. The existing certificate expires in April 2021. When the new certificate is installed on March 29, 2021, Jenkins versions older than 2.178 (April 2018), won’t be able to communicate with the default and experimental update centers. Instances using alternative update centers (self-hosted or vendor-provided) will not be affected by this change. Regarding plugins update, the update-center usually supports up to one-year-old Jenkins core versions with 2.204 being the oldest version supported.

If you don’t update regularly, please review the Jenkins security advisories and use this change as your motivation to update to a more recent Jenkins version.

Who

Jenkins users running Jenkins versions older than 2.178 will not see any further updates after the update center certificate change March 29, 2021.

Jenkins developers will not see plugin updates when they use mvn hpi:run to test their plugin if the Jenkins version is older than 2.178. Plugin developers can update their minimum Jenkins version to a newer Jenkins version. Refer to the guidelines in "Choosing a Jenkins version" when selecting the new minimum Jenkins version. Plugin developers may also be able to test with a newer Jenkins version using arguments like mvn -Djenkins.version=2.249.1 hpi:run.

Jenkins users running versions 2.178 or newer are not affected by this change.

What

Jenkins uses the update center to identify updates to core and to plugins. The service signs its metadata with a certificate that is cross-signed by a root certificate. Jenkins is bundled with the root certificate so it can confirm the authenticity of update center data. When updates are available, an alert is shown to Jenkins users that reminds them to update.

Why

The root certificate bundled in Jenkins was created in April 2011 and will expire in April 2021. We prepared for this rotation in April 2018 when we bundled the new root certificate with Jenkins core releases. It’s now time to use the new root certificate with a new update center certificate. The new root certificate will expire in April 2028.

You can follow the work for this certificate rotation in this ticket INFRA-2902

So again, keep your instance updated and everything should be fine.

See you in 2028,

Various Links:

• INFRA-2902 - Rotate the update center certificate

• INFRA-2732 - Annual certificate update

• INFRA-1502 - Add new root certificate (2018)

• jenkins-infra/update-center2 - Jenkins update center certificates

• updates.jenkins.io - Jenkins update center

• advisories - Jenkins security advisories

---

Jenkins accepted in Google Summer Of Code 2021!

October 17, 2021, 5:42 am

≫ Next: Jenkins accepted in She Code Africa Contributhon

≪ Previous: Update-Center certificate rotation

$

0

0

On behalf of the Jenkins GSoC org team, I am happy to announce that this year, for the first time, the Jenkins projects will be participating inGoogle Summer of Code 2021 as part of theContinuous Delivery Foundation (CDF) GSoC organization.

We’re very excited to have the Jenkins project participate in GSoC as part the CDF mentoring organisation along with fellow CDF projects such as Ortelius, Screwdriver, Spinnaker, and Tekton. We believe that being part of the CDF GSoC org will create an environment for students with even more mentoring channels, potential cross-fertilization of ideas, and an even greater community of DevOps practitioners to join!

What’s next? GSoC is officially announced, and please expect more students to contact projects in ourGitter channels and mailing lists. Many communications will also happen in SIG and sub-project channels. Also, please join the gsoc channel on the CDF Slack. We will be working hard in order to help students to find interesting projects, to explore the area, and to prepare their project proposals before the deadline on April 13th. Then we will process the applications, select projects and assign mentor teams.

All information about the Jenkins GSoC is available on its sub-project page.

I am a student. How do I apply?

See the Information for students page for full application guidelines.

We encourage interested students to reach out to the Jenkins community early and to start exploring project ideas. All project ideas have chats and mailing lists referenced on their pages. We will be also organizing office hours for students, and you can use these meetings to meet org admins and mentors and to ask questions. Also, join our Gitter channel and themailing list to receive information about such incoming events in the project.

The application period starts on March 29th, but you can prepare now! Use the time before the application period to discuss and improve your project proposals. We also recommend that you become familiar with Jenkins and start exploring your proposal areas. Project ideas include quick-start guidelines and reference newbie-friendly issues which may help with initial study. If you do not see anything interesting, you can propose your own project idea or check out ideas proposed by other CDF organizations participating in GSoC.

I want to be a mentor. Is it too late?

It’s not! We are looking for more project ideas and for Jenkins contributors/users who are passionate about Jenkins and want to mentor students. No hardcore experience required, mentors can study the project internals together with students and technical advisors. We are especially interested in ideas beyond the Java stack, and in ideas focusing new technologies and areas (e.g. Kubernetes, IoT, Python, Go, whatever).

You can either propose a new project idea or join an existing one. See the Call for Mentors post and Information for mentors for details. If you want to propose a new project, please do so as soon as possible so that students have time to explore them and to prepare their proposals.

This year mentorship does NOT require strong expertise in Jenkins development. The objective is to guide students and to get involved into the Jenkins community. GSoC org admins will help to find advisers if special expertise is required.

Testimonials from former Jenkins GSoC participants ❤️

"I participated in Google Summer of Code 2020 in cooperation with the Jenkins organization and I work on a project called Windows Service Wrapper, which allows running Jenkins as a service on a Windows machine. GSoC was the most wonderful and the most valuable experience I gained during my student life. The whole journey was full of experiences and Jenkins mentors always were there for us. I experienced a huge development of my skills while I was working on the project. I had many meetings, knowledge sharing sessions, and one pair-coding session with my mentors. One of the best things that I learned is the open-source community and open source mentality. It is not only about taking, but also about giving. Today I am maintaining an open-source project which is a simple programming language for kids which allows them to code in their native language, which will help to learn coding to students in rural areas of my country. Finally, Jenkins is a wonderful family and they always were there for us in all the ups and downs. I am proud to be a part of the Jenkins community."

• Buddhika Chathuranga, GSoC 2020 student, Support for YAML Configuration in Windows Service Wrapper

"My GSoC journey in the Jenkins community starts by a draft proposal full of comments from mentors and ends by two plugins with hundreds of installations. Along with the daily coding review, the weekly meeting and the growth of the project, I increased my skills on programming and became a much more eligible engineer. What is more, the support from the whole Jenkins community leads me to a broader career path. I learned how to maintain a project, how to communicate with users and other developers on GitHub. Most importantly, the Jenkins community teaches me the principles of the open source world and welcomes me to the open source world with all their kind help."

• Kezhi Xiong, GSoC 2020 students, GitHub Checks API project

"I worked as a Google Summer of Code student with the Jenkins project during the summer of 2019. The project provided me with an excellent opportunity to contribute to the world’s most popular automation server, learn about building performant and reliable applications, and interact with awesome people around the globe. Jenkins' ever helpful and extremely knowledgeable community made working on my project a real treat. I even got a chance to present my project at DevOps World in Lisbon! If you’re deciding which organization to work for this year, choose the Jenkins project — you can’t have a better GSoC experience than this!"

• Abhyudaya Sharma, GSoC 2019 student, Role Strategy Performance Improvements

"I participated in Google Summer of Code 2018 with Jenkins as a student developer. Working for Jenkins in GSoC 2018 was one of the best experiences I have ever had. During 3 months of summer, I learned a lot of new things when working on the open-source project with Jenkins. Another best thing about Jenkins is the people, I received a lot of support from my mentors and other developers from the Jenkins community when working on my project. After GSoC, I also had a chance to go to the Jenkins World Conference in San Francisco to meet and connect with my mentors and other people in the Jenkins community. Overall, GSoC with Jenkins was a great experience and I highly recommend Jenkins as a great community to kickstart your open source journey."

• Pham Vu Tuan, GSoC 2018 student, Remoting over Apache Kafka project

Important dates for GSoC 2021

• Apr 13 - deadline for student applications

• May 17 - accepted projects announced, teams start community bonding and coding

• Aug 16 - coding period ends

• Aug 31 - Results announced

See the GSoC Timeline for more info.

Jenkins accepted in She Code Africa Contributhon

October 17, 2021, 5:42 am

≫ Next: Welcome Ewelina Wilkosz - new Jenkins Governance Board member

≪ Previous: Jenkins accepted in Google Summer Of Code 2021!

$

0

0

She Code Africa is a non-profit organization focused on celebrating and empowering young girls and women in technology across Africa. They provide resources and events that help women grow and achieve their personal and career goals. Their mentoring programs provide help and guidance as participants learn and grow in their careers.

This year, She Code Africa is organizing the She Code Africa Contributhon. Contributhon is a boot camp where African women are paid to work with open source organizations on selected projects with dedicated mentors. This program aims to create a more diverse, inclusive, and innovative culture within the African open source ecosystem by matching African women in technology with sponsor and mentor open source organizations.

Jenkins in She Code Africa Contributhon

The Jenkins project has been accepted as a Contributhon mentoring organization. Our project idea will introduce participants to Jenkins and plugin development as they create Pipeline examples and create Pipeline help for Jenkins Pipeline plugins. Participants will learn more about Jenkins Pipeline and will submit plugin pull requests with examples and online help.

The Jenkins Pipeline Steps Reference and Pipeline online help often receive feedback that more examples are needed, that step return values need to be described, and that arguments need more description of their purpose, allowed values, and expected results. Most plugin maintainers do not provide detailed documentation of the pipeline steps, or the arguments to those pipeline steps. This project will improve the documentation of pipeline steps and their arguments while introducing Jenkins Pipeline, Jenkins plugin development, Jenkins documentation as code, and the concepts of GitHub forks and pull requests.

We’ve identified development tasks that up to three Contributhon participants will complete during April. The tasks will introduce the participants to Jenkins plugin development. They will experiment with plugin changes in Jenkins and submit pull requests to provide Pipeline examples and help. They will meet twice a week with Jenkins mentors, Kristin Whetstone, Mark Waite, and Meg McRoberts to review their progress, provide coaching, and help with issues.

Data driven choices

We’ve been collecting Jenkins documentation feedback since 2017. Now we’re using that feedback to prioritize the plugins to improve as part of this project. The top 10 Pipeline plugins that have received the most feedback are:

• Build step

• SCM step

• Git step

• Input step

• Nodes and processes steps

• Workspace cleanup step

• Basic Pipeline steps

• Slack notification steps

• HTTP request step

• Email extension steps

What about my plugin?

If you are a plugin maintainer and would like help to add examples and online help for the Pipeline steps in your plugin, send email to the Jenkins Documentation mailing list. We’ll consider including additional plugins as we better understand the development pace for She Code Africa participants.

Welcome Ewelina Wilkosz - new Jenkins Governance Board member

October 17, 2021, 5:42 am

≫ Next: Welcome the She Code Africa Contributhon participants!

≪ Previous: Jenkins accepted in She Code Africa Contributhon

$

0

0

We would like to announce changes in the Jenkins Governance Board. As it was announced earlier this month, Marky Jackson has decided to step down from his elected roles. On behalf of the Jenkins community, we would like to thank Marky for all contributions and for the continued participation in the Jenkins community. As an active Jenkins contributor and community leader, Marky helped a lot of initiatives to happen: Jenkins and Kubernetes ecosystem, terminology changes, GSoC and GSoD, pipeline authoring SIG and many more activities. Thank you Marky!

The governance board has followed the interim procedure to nominate the new governance board member until the end of the term. The board decided to respect the results of the 2020 elections and to nominate Ewelina Wilkosz who received the most of the votes after the elected candidates. She has accepted the nomination, and on March 10th the Governance Meeting has confirmed it. We are happy to welcome Ewelina Wilkosz as a new Governance Board Member!

Ewelina will join other governance Board Members:Kohsuke Kawaguchi,Ullrich Hafner,Oleg Nenashev, andGavin Mogan. The term will last until December 2022.

About Ewelina Wilkosz

Ewelina has been a Jenkins Contributor since 2017, when she got involved in Jenkins Configuration as Code Plugin development. Voted Most Valuable Jenkins Contributor in 2018. She has 14 years of experience in IT, working as a CI/CD consultant since the beginning of 2017. In that role she’s trying to solve numerous issues Jenkins users are facing daily - as developers, administrators, maintainers.

Here is Ewelina’s statement from the elections:

As a consultant I support my customers with their Jenkins issues since the beginning of 2017. And almost from the start it was some kind of "as code" approach. The experience I gained during that time resulted in getting myself involved in the development of Configuration as Code Plugin for Jenkins. I consider becoming a part of Jenkins Community one of the most valuable experiences in my career so far. I appreciate how much I have learned and how welcoming the community is.

I am not a very active contributor these days, at least when it comes to code, but what I have to offer is rather extensive experience with Jenkins end users - from small, single instance setups to environments with hundreds of controllers run in a different way on different operating systems. Every day I see challenges those users go through, I know what issues they are facing and which features they consider valuable or missing. As a Jenkins Governance Board Member I can represent those users.

Thanks to my involvement in Configuration as Code Plugin development I had a chance to deliver a number of public presentations where I focused on the benefits of the solution and tried to make it easier for newcomers to try it. Here are a few examples of my activities related to Jenkins Configuration as Code:blogpost,cdCON presentation,podcast recording. So my focus is not only on representing users but also on educating them, and educating myself, so I actually know what they need and why.

What’s next for the Jenkins Governance Board?

In February we had the Jenkins Contributor Summit. There we discussed many topics related to the Jenkins evolution and its roadmap. We identified several initiatives we would like to focus on, including but not limited to improving user experience, contributor onboarding, and securing Jenkins delivery pipelines. These initiatives will be a key focus until the next contributor summit we plan to organize in June. The board will also focus on maintaining the Jenkins governance processes (meetings, budget approvals, funding, etc.) and facilitating contributions to the project.

Participating in Jenkins Governance

Jenkins Governance Board has just a representative function in the community. The project and the community have a long history of open and inclusive governance driven by many contributors. We invite all community members to participate in the project by joining thegovernance meeting, participating in the mailing list conversations, and joining special interest groups driving particular topics.

See this page to know more about contributing to Jenkins in general.

Welcome the She Code Africa Contributhon participants!

October 17, 2021, 5:42 am

≫ Next: Jenkins Operator becomes an official sub-project!

≪ Previous: Welcome Ewelina Wilkosz - new Jenkins Governance Board member

$

0

0

The She Code Africa Contributhon started April 1, 2021. The She Code Africa Contributhon is a boot camp where African women are paid to work with open source organizations on selected projects with dedicated mentors. This program aims to create a more diverse, inclusive, and innovative culture within the African open source ecosystem by matching African women in technology with sponsor and mentor open source organizations. The 5 mentees joining the Jenkins project come from Nigeria, Kenya, and Rwanda.

The Jenkins project has been accepted as a Contributhon mentoring organization. Our project idea will introduce mentees to Jenkins and plugin development as they create Pipeline examples and create Pipeline help for Jenkins Pipeline plugins.

Twice weekly mentoring sessions are scheduled with the mentees and are listed in the events calendar. We’ve already received the first pull request to improve the embedded documentation that generates the Steps Reference and provides contextual help in the Snippet Generator. We’re looking forward to more pull requests and more improvements throughout April, 2021.

We’d like to introduce our mentees so that you recognize them and can welcome them during code review and online chat.

Onyinye Ezike

Onyinye is based in Lagos, Nigeria. She’s a junior fullstack software developer who is very passionate about learning. She uses Angular, React, Nodejs, and Spring Boot. She has spent the last two years building up herself in software development and she’s hoping to become a world-class software developer.

You’ll recognize her contributions as Onyimatics on GitHub and on the Jenkins issue tracker.

Sharon Jebitok

Sharon is based in Kenya. She’s a software development student at Microverse, a remote school for software developers. She has been an active member of She Code Africa and she’s presently a mentee on She Code Africa’s Contributhon Program with the Jenkins project. She has spent one year in the software industry since she switched her career into tech, learning to write meaningful code and collaborate with other developers/designers and the tech community.

You’ll recognize her contributions as jebitok-dev on GitHub and as jebitok16_ on the Jenkins issue tracker.

Esther Ejidike

Esther is a frontend developer based in Lagos, Nigeria. She is one of the participants in the She Code Africa Contributhon Open Source Program working with Jenkins and will be contributing to the nodes and processes plugin. She loves to convert designs to exact replicas in the form of webpages and she likes to learn new things in her free time.

You’ll recognize her contributions as Queen-esther01 on GitHub and as esther101 on the Jenkins issue tracker.

Cynthia Iradukunda

Cynthia Iradukunda is based in Kigali, Rwanda. She is currently a junior Computing student at the African Leadership University (ALU) in Mauritius. She wants to be a software engineer because it will help her solve real-world problems while also allowing her to use her coding skills. Her coding skills include but not limited to Java, JavaScript, and attention to detail. By contributing to the Git plugin, she hopes to help users have a smooth process using its documentation, get involved with the project, and connect with other community members.

You’ll recognize her contributions as ciradu2204 on GitHub and as ciradu2204 on the Jenkins issue tracker.

Lucy Karimi

Lucy is based in Nairobi, Kenya. She is a software developer with experience in mobile app development. She is very passionate about tech and is currently involved in the SheCodeAfrica Contributhon.

You’ll recognize her contributions as luciahroyalty101 on GitHub and as luciahroyalty101 on the Jenkins issue tracker.

About the Contributhon projects

See the previous blog post for more information about She Code Africa, the Contributhon, and the plans for Jenkins.

• Jenkins development tasks

• She Code Africa Contributhon mentoring organizations

• She Code Africa Contributhon

• She Code Africa

Conversations related to the Contributhon are happening in a Continuous Delivery Foundation slack channel.

Mentors

We’re very grateful to the mentors from the Jenkins project that are hosting mentoring sessions, reviewing pull requests, and encouraging the mentees. Thanks to:

• Meg McRoberts

• Mark Waite

• Kristin Whetstone

• Oleg Nenashev

• Angélique Jard

We also thank Zainab Abubakar of She Code Africa for her efforts to facilitate the Contributhon and encourage participation.

Jenkins Operator becomes an official sub-project!

October 17, 2021, 5:42 am

≫ Next: Easily reuse Tekton and Jenkins X from Jenkins

≪ Previous: Welcome the She Code Africa Contributhon participants!

$

0

0

We are happy to announce that Jenkins Operator officially became an official Jenkins sub-project.

What does it mean for the project?

Becoming an official part of the Jenkins project was a major step towards better alignment with the overall Jenkins’ roadmap and more opportunities to increase adoption of the Jenkins Operator project.

Finally, with a dedicated team at VirtusLab actively maintaining the project we can engage with the wider community and participate in some of the Cloud-Native SIG meetings.This opens a room for everyone to voice their opinions or start supporting the project.

We truly believe that this community engagement will result in significant improvements to Jenkins Operator, as well as the Jenkins ecosystem itself.

Bridging the gap between Jenkins and Kubernetes

Running Jenkins in a cloud-native environment like Kubernetes is not a trivial task. With Jenkins Operator project we want to enable the community to take full advantage of Kubernetes and public cloud capabilities by:

• native integration with public cloud services in areas of observability, storage and cloud security

• Kubernetes autoscaling and self-healing mechanism

• secure access to Jenkins instance

• declarative configuration using Kubernetes Custom Resources

• full lifecycle management, eventually transforming it to autopilot

Take part in the journey toward global trends

Start contributing and play an important role in creating the automated Jenkins experience! Don’t hesitate - engage in the community. Join us in our work of creating the functionalities you see beneficial. You are welcome to create issues and pull requests. We are actively resolving community issues and providing answers on a dedicated Slack channel.

As the project has been initially developed and still actively maintained by VirtusLab, we started discussion towards an open governance model to facilitate communication and collaboration.

Lead the way we are heading by providing us feedback

To celebrate the new possibilities that are being opened for our project, we would like to invite you to take part in a short survey that will help put us on the right track. If you have been using Jenkins Operator or running Jenkins in any other environment, please take a moment to fill out our quick survey.We will choose at least three of the most informative answers and send you an awesome Jenkins Operator T-shirt with our cute Gopher butler. The survey can be found here. Remember, the most sincere answers are the best.

And if you still haven’t used Jenkins Kubernetes Operator, you’re more than welcome to do so. Give it a shot and discover a new kind of simplicity of running Jenkins.

How to get started.

Easily reuse Tekton and Jenkins X from Jenkins

October 17, 2021, 5:42 am

≫ Next: Jenkins Contributor Awards - Nominations Open

≪ Previous: Jenkins Operator becomes an official sub-project!

$

0

0

What is Tekton?

Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premises systems.

Why use Tekton?

Tekton pipelines have a number of benefits:

• they are cloud native and designed from the ground up for kubernetes

• each Tekton Pipeline is fully declarative and completely self described; it does not depend on any separate out of band Jenkins controllers, plugins or plugin/controller configurations

• each Pipeline Task runs as a stand alone kubernetes Pod which is completely independent of any other pods and pipelines and are fully scheduled by Kubernetes to maximise resilience and optimize resource usage. A bad pipeline cannot take down another one & the kubernetes scheduler manages them all

• each step can be any command in any container image with whatever secrets, volume mounts, environment variables and resource limits you need

• there is no need to bundle a JVM or Jenkins Remoting container into the pod so you can keep resources and cost down

Why use Jenkins and Tekton together?

Jenkins is the most popular open source automation server around. Lots of developers use it every day to get things done. Jenkins can now be used to automate Tekton pipelines too which helps teams digitally transform to more cloud native solutions for their CI and CD. In such a case, you can use Tekton pipeline engine while getting all benefits from Jenkins as an orchestrator, user interface and the reporting engine.

Introducing the Tekton Plugin for Jenkins

The Tekton Client plugin for Jenkins lets you easily use Jenkins to automate creating and running Tekton pipelines. It bridges the Kubernetes learning gap and allows invoking Tekton Pipelines and resources through Jenkins. This allows users to not have much of the Kubernetes specific knowledge beforehand and work.

Its a single Jenkins plugin to install - so it’s easy to use.

For background check out the blog post Bridging the Gap with Tekton-client-plugin for Jenkins by the founder of the plugin Vibhav Bobade.

Requirements

The Tekton Client plugin for jenkins assumes you have access to a kubernetes cluster.

The kubernetes cluster should have Tekton pipelines installed.

If you have not yet installed Tekton you could use this tekton helm chart

The Jenkins controller should also have kubernetes RBAC access to be able to create Tekton resources and watch them and their associated pods and pod logs.

If you are running your Jenkins controller inside Kubernetes then an easy way to setup the RBAC is to install the Jenkins Resource Helm Chart in the same namespace as your Jenkins controller.

Another option is to use an installation of Jenkins X and let it setup a Jenkins controller via GitOps

Specifying the Tekton pipelines

You can configure the Tekton pipeline via:

• a file path in a git clone block

• a URL to a tekton YAML file

• a block of YAML

We recommend defining Tekton pipelines as YAML files and checking them into a git repository so that you can use GitOps and follow the Pipeline As Code pattern.

This means that you can version your pipelines in git. It also means you can benefit from the various IDE plugins available for Tekton such as VS Code and IDEA so that you get auto completion, formatting and validation while editing the YAML.

So you can use the usual Git provider support in Jenkins to clone the git repository that contains then Tekton YAML file then reference the file by name.

Reusing Pipelines from the Tekton Catalog

The Tekton Catalog defines a ton of Tekton Tasks you can reuse in your pipelines

We have found when it comes to a microsevices style architecture you end up with lots of repositories and pipelines. Then using a Pipeline As Code pattern with GitOps we want to Version Everything but also make it easy for any repository to use any version of any task or pipeline.

e.g. you may have many repositories using the current version of a pipeline but want to try out a new change to the pipeline in just 1 repository to verify it works well; then if it does, incrementally roll that change out to more repositories.

This can make it hard trying to reuse as much as you can across the different git repositories while also minimising the number of versions and forks of git repositories you have and simplifying the maintenance of all of the pipelines.

We have found on the Jenkins X project that a nice way to do this via GitOps such that we reference versioned Tekton Tasks and Pipelines in git so that they are easy to reuse or override.

So we reuse Tasks and Pipelines via the uses: image notation which lets us keep all of our Tekton Tasks and Pipelines in vanilla Tekton YAML; so that the IDE completion and validation works - but we can easily reuse Tasks or steps from libraries while also Versioning Everything

Note that if wish to reuse steps/tasks via the uses: image notation then you must click the Tekton Catalog flag in your Job definition which will then resolve the uses: clause with the actual step/task.

What is Jenkins X?

The Jenkins X project automates your CI/CD on kubernetes to help you accelerate:

• Automated CI/CD pipelines lets you focus on your actually application code while Jenkins X automatically creates battle tested Tekton CI/CD pipelines for your project which are managed via GitOps so that its super easy to keep your pipelines up to date across your repositories or to upgrade or override pipelines or steps for specific repositories.

• Automatic promotion of versioned artifacts via GitOps through your Environments such as Staging, Pre-production and Production whether they are running in the same kubernetes cluster or you are using multiple clusters for your environments

• Preview Environments lets you propose code changes via Pull Requests and have a Preview Environment automatically created, running your code in kubernetes to get fast feedback from your team before agreeing to merge changes to the main branch

• ChatOps comment on Pull Requests to give feedback, approve/hold changes, trigger optional pipelines for additional testing and other ChatOps commands

All of the above is implemented in reusable Tekton pipelines.

Reusing Jenkins X Pipelines

So how can we reuse automated CI/CD pipelines from Jenkins X project from Jenkins?

Make sure you have the Tekton Client plugin for Jenkins installed in your Jenkins server.

Using a working template

If you want to start with a working example then

• Create A Git Repository From This Template

• add a new Frestyle project to your Jenkins server

• enable the Git source code management for your new github.com repository

• click Add build Step (near the bottom of the page) and then select Tekton : Create Resource (Raw)

• make sure that FILE is selected for the input and enter the name .lighthouse/jenkins-x/release.yaml for the file name

• if you are using a Jenkins X cluster enter jx for the namespace

• ensure that Enable Tekton Catalog is checked

• now save the pipeline - it should look something like this:

Now if you trigger the pipeline you should see it create a Tekton Pipeline and you should see the output of the tekton pipeline in the Jenkins console. The pipeline is actually running as a completely separate Pod in kubernetes; the Jenkins controller just tails the log into the console.

In a Jenkins X cluster this pipeline should just work (reusing all the cloud resources and IAM roles setup by the Terraform) but in an arbitrary kubernetes cluster you may get issues around not being able to push images or promote due to lack of GitOps environments being defined which we can help you work through via the Jenkins X slack room

Using an existing repository

You can configure a Pull Request or Release pipeline in your project by copying the YAML file for the language pack you wish to use.

e.g. if you are using maven then copy pullrequest.yaml or release.yaml into your projects source code then reference it from your Jenkins Job:

Then follow the above instructions for setting up a Freestyle project for your git repository and referencing the file name for your pipeline.

Overriding steps

Being able to reuse steps from libraries of pipelines is awesome; but sometimes you need to change things. The assumptions, commands, arguments, environment variables or approaches used for every step in a library may not quite match what you need on a specific application. You may need to run steps before/after steps in the library or you may need to override a specific step to do something different.

You can easily customize any inherited step in any shared pipeline or add custom steps before/after any step.

The fact that all the Tekton YAML is fully declarative makes it super easy to modify things via your IDE with validation and smart completion and not have to use a scripting language and understand complex shared pipeline libraries.

The easiest way to try overriding a step is to install the jx binary to your $PATH then use the jx pipeline override command which will create a new locally overridden step you can then just edit in your IDE.

Then at any time you can view the effective pipeline when you make local changes

Comparing the Kubernetes and Tekton plugins

Those of you using Jenkins on a Kubernetes cluster are probably using the kubernetes plugin right now.

Here is an example of how to use a Jenkinsfile with a pod YAML file so that you can run commands in different containers in the pod.

What this means is that:

• a kubernetes pod is created based on the pod YAML file which is scheduled by kubernetes

• the Jenkinsfile runs on the Jenkins controller talking over Jenkins remoting to the pod to tell it to run commands in different containers. The pod includes the jnlp container which does the remoting between the Jenkins controller and the pod

This has a few issues:

• each container in the pod must have a shell so that jnlp can invoke commands. This may mean you have to create your own images

• it can be a little slow to start since there is chattiness with the Jenkins controller and the pod - whereas with Tekton pods just start and run locally without any coodination with the Jenkins controller

• you have to maintain 2 files: the Jenkinsfile and the pod.yaml and it’s hard to share/override both of those files across multiple repositories as you need to make changes (e.g. overriding environment variables/images/commands/resource limits on demand on steps).

Though one downside of the tekton approach is that by default there is no automatic synchronisation of state; after a Task in tekton completes there’s no automatic upload of state to the Jenkins controllers disk. You can always add a step in your Task to upload workspace state to the Jenkins controller if that’s what you want.

Though remember that tekton plugin doesn’t take anything away; so you can mix and match the kubernetes and tekton plugins to suit your needs.

Conclusion

We are really excited about the combination of Jenkins, Tekton and Jenkins X letting developers pick the best tool for the job while becoming more cloud native and increasing the automation help reduce the amount of manual work creating and maintaining pipelines while also helping to improve the quality and practices of our CI/CD.

Please try it out and let us know how you get on!

Jenkins Contributor Awards - Nominations Open

October 17, 2021, 5:42 am

≫ Next: Configure Plugins with JCasC

≪ Previous: Easily reuse Tekton and Jenkins X from Jenkins

$

0

0

This year, the Jenkins Contributor Awards will be run by the Continuous Delivery Foundation (CDF) along with many other CDF Community Awards.

The nominations are currently open and are being accepted using GitHub issues to make the process more transparent. Any contributor is eligible this time around! The deadline to nominate someone is May 14, 2021, and voting will open in May.

Nominate contributors or vote with reactions/comments for all three Jenkins awards:

• Most Valuable Jenkins Contributor

• Most Valuable Jenkins Advocate

• Jenkins Security MVP

The winners will be announced at cdCon 2021, where we’re also co-locating the Jenkins Contributor Summit on June 25, 2021!

You can also nominate Jenkins community members for global awards like "Top CDF Ambassador" or "Top GitOps Evangelist"! For all CDF Community Awards and more details, visit the CDF Award Page.

---

Configure Plugins with JCasC

October 17, 2021, 5:42 am

≫ Next: Apache Commons Digester library removal (breaking changes!)

≪ Previous: Jenkins Contributor Awards - Nominations Open

$

0

0

This blog post is for anyone interested to know how to configure a plugin using the Jenkins Configuration as a Code (JCasC) plugin, more specifically, this blog will guide you to get the YAML equivalent of a plugin’s configuration and use it to do some changes to the plugin without using the Jenkins UI.

---

If you’re a beginner at JCasC and want to learn more about it, you can head over to the following resources to understand JCasC better:

• JCasC Documentation

• Overview of JCasC (Video Presentation)

• Manage JCasC (DevOps World 2018)

---

Configuring your first plugin using JCasC (Video Demo)

---

Overview

So, these are the steps we will be following to achieve our aim:

1. Brief Introduction to jenkins.yaml file

2. Configure the plugin on the UI

3. Download the Configuration

4. Update JCasC file locally

5. Load the jenkins.yaml file on the Jenkins server

6. Verify the changes on the UI

---

Brief Introduction to jenkins.yaml file

• The jenkins.yaml file contains the configuration of the Jenkins instance in YAML format. The JCasC plugin refers to this file to configure the Jenkins instance.

• The default location of jenkins.yaml is $JENKINS_HOME/jenkins.yaml, from where it can be fetched into the Jenkins server whenever you apply a new configuration.

• Download your jenkins.yaml file by going to Manage Jenkins> Configuration as Code> Download Configuration.

• Make sure this file is saved at location $JENKINS_HOME/jenkins.yaml.

• Let’s change the systemMessage field to:

Figure 1. Updating the jenkins.yaml file

• Reload the existing configuration to apply the system message change

• Now, go back to the Dashboard and you can see the updated System Message on top:

Figure 2. Viewing the changes on Dashboard

• This file will be used later to configure the plugin using JCasC.

---

Configure the plugin on the UI

• For this demo, install the View Job Filters plugin.

• Let’s create a view by clicking on the New View option on the left side of the Dashboard.

• Give it a name (say, “testView”) and set its type to List View, and click on the OK button.

Figure 3. Creating the View

• Now click on Add Job Filter to add any kind of filter, so let’s select Build Duration Filter and fill the field with any value (say, "60" minutes),

Figure 4. Adding filter to the view

• Click on Apply> Save.

• To view the full configuration, check out your main jenkins.yaml configuration file, by clicking on Manage Jenkins> Configuration as Code> View Configuration

• Go to the views section in this YAML file to see details related to the view,

Figure 5. Here, details regarding the view (which we just created) is visible

---

Download the Configuration

• Now that you have successfully configured your plugin by UI, let’s download the configuration by going to Manage Jenkins on the Dashboard, then click on Configuration as Code under "System Configuration".

• Now click on the Download Configuration button to save the configuration file locally.

Figure 6. Downloading the Configuration

---

Update JCasC file locally

• Add some changes in your downloaded copy of the jenkins.yaml file, to see those changes being automatically reflected on the UI.

• For demo purposes, let’s change the name to “YoutubeDemoView” and set the buildDurationMinutes as "55".

Figure 7. Changing the View details locally

• Save the file.

---

Load the jenkins.yaml file on the Jenkins server

• Now to reflect the local changes done in the jenkins.yaml file onto the Jenkins server, click on the Reload existing configuration button.

Figure 8. Applying the New Configuration to the Jenkins instance

---

Verify the changes on the UI

• Go back to the main page by clicking on the Jenkins logo on the top-left side.

• And you will notice that the name of your view has been changed from "testView" to “YoutubeDemoView”,

• And the field value of Build Duration Filter has been changed from "60" to “55”.

• These two are the exact changes that we did locally in our jenkins.yaml file.

Figure 9. Verifying the changes

Congratulations! You’ve successfully configured a plugin (“View Job Filter”) automatically with the help of the “Jenkins Configuration as Code” plugin! You can repeat the same process for other plugins as well.

---

Apache Commons Digester library removal (breaking changes!)

October 17, 2021, 5:42 am

≫ Next: New eBook: Jenkins is the Way for IT and software developers

≪ Previous: Configure Plugins with JCasC

$

0

0

Keeping up with our goal to clean up some of the technical debt inside Jenkins Core and reduce the maintenance overheads, we are happy to report we were able to remove a long-deprecated Apache Commons Digester library.

Jenkins Core does not depend anymore on Apache Commons Digester v.2.1, a version that has been released in 2010.

Some plugins will require update to operate properly after the Jenkins core upgrade. See JEP-231 for the full list of the affected plugins. Below there is the list of plugins that did not have their fix released at the time of writing. They will start to break with the weekly on the 7th of June, expected to be the 2.297.

• teamconcert

• vs-code-metrics

• BlameSubversion

• javatest-report

• vss

• synergy

• config-rotator

• harvest

• cmvc

In addition to these still-served plugins, a few others will break. Note however that these were already suspended ^[1] for various reasons, so we do recommend to move away from using them or step up as maintainers. The IDs for these plugins are: tfs, svn-release-mgr, cpptest, cflint, script-scm, rtc.

It is always a good idea to update all your plugins before upgrading Jenkins core.

Please reach out on the developers’ list with any questions or suggestions.

Getting fixes in the affected plugins

For all affected plugins we have submitted pull requests with compatibility patches. These plugins seem to have no active maintainer, and hence we cannot commit on delivering those fixes. In mean time you can build a custom patch locally to resolve the issue on your instances. If you use any of those plugins, consider stepping up and adopting them so that the fixes could be released. We will appreciate any contributions!

Resources

PR-5320

removing commons-digester:2.1. This also contains a complete list of impacted plugins and their PRs and statuses.

JEP-231

describing this change.

---

1. this means these plugins are not served anymore by the Jenkins Project’s hosting service. Even if they were released, the releases would not show up until additional issues are fixed.

New eBook: Jenkins is the Way for IT and software developers

October 17, 2021, 5:42 am

≫ Next: Jenkins IRC moves to Libera Chat

≪ Previous: Apache Commons Digester library removal (breaking changes!)

$

0

0

A little over a year ago, we launched JenkinsIsTheWay.io, a website whose sole purpose is to share Jenkins user stories with the developers and engineers in our community. Over a hundred of you have already shared your innovations, and they just keep coming. It comes as no surprise that many of the submitted stories are from IT consultants and software developers around the world building next-generation DevOps and CI/CD platforms to fuel the modernization of enterprise companies far and wide.

That’s why we’ve dedicated our latest eBook to focus on Jenkins users in the global Information Technology sector. We shine the spotlight on these developers and engineers who have solved unique software development and DevOps challenges by turning to the leading open source automation server. From powering large enterprises needing a better way to manage their inventory to innovative tech firms looking to advance technologies and healthcare initiatives during a pandemic, you’ll read about how teams everywhere solved their unique challenges — with the help of Jenkins.

Jenkins is the Way to…

In our short User Story Survey, we ask Jenkins users to fill in the blank: Jenkins is the way to …​…​

We’ve seen results-oriented submissions like "Jenkins is the way to deliver our new releases on time!" and "Jenkins is the way to understand and simplify your software workflows." Several submissions riffed off of something like "Jenkins is the way to completely automate your CI/CD workflow." Meanwhile, others have had a bit more fun and languished praise on Jenkins, stating, "Jenkins is the way to help teams focus on what is really important, make our life easier" and, even, "Jenkins is the way to save the day."

In this new eBook, we focus on the challenges users in the community face, and what they’ve built using Jenkins to achieve their unique goals. For example, Build & Release Manager, Donald Morton, turned to Jenkins to establish a flexible, modern, and more efficient DevOps platform for Graylog, a leading log management platform serving the enterprise.

With a Jenkins assist, Mark Baumann, DevOps Engineer with ITK Engineering, created “one CI to rule them all.” He told us that “Jenkins provides a common CI/CD platform for all different kinds of projects and technology domains.”

When IBM Lead Software Engineer Alec Rieger sought to simplify the build and testing pipeline for the company’s software engineers and developers, he also turned to Jenkins. For a company the size of IBM, which services enterprise clients worldwide, Rieger wanted to help his colleagues manage many nodes on a large scale. Now, according to his Jenkins Is The Way user story, IBM uses Jenkins pipelines for each of their builds and relies on the flexibility and countless plugin features to continually improve their processes.

Stronger, Smarter, Faster Software Innovation

While we all fondly think of Jenkins as a modest butler who has empowered developers with the open-source tools they need to succeed — on JenkinsIsTheWay.io, we liken him to an unpretentious, yet powerful superhero. And like any great superhero, he (or she!) is sure to save the day.

For our Jenkins users, that means results — significant, measurable results with a common theme. Using Jenkins has enabled you — the user — to help the businesses you serve save money, spin up software faster, and automate processes. In doing so, you’ve freed up developers and engineers from countless hours of mundane tasks. Thanks to Jenkins, you’re empowering entire IT teams to innovate, focus on what they love to do and, ultimately, build great stuff.

Of course, we devote much of our latest eBook to those victories. Results like how RedHat’s releases are 5x faster thanks to Jenkins. The fact that DevOps problem tickets were reduced by over 90% for Electronic Health Solutions. And why the CTO at Cloudologia was psyched to share that — with a Jenkins at the helm — they were able to shorten onboarding for deployment & build release cycles from one week to a single day.

Share Your User Story, Too!

I am proud to share another common theme from the users who have submitted their story: you turn to our community for collaboration, guidance, and advice. A community of a million strong and growing, this eBook and JenkinsIsTheWay.io are other ways to provide you with the insight and lessons learned by developers and engineers, like you, to innovate and build next-generation technologies for companies of all sizes.

When you’re ready to tell your story, we’re prepared to help you share it. Fill out our short questionnaire, and we’ll send you our Jenkins Is The Way T-shirt as a thank you once it’s published!

Links

• Jenkins IsThe Way. IT User Story eBook, chapter 2

• Jenkins IsThe Way. IT User Story eBook, chapter 1

• Visit Jenkins Is The Way

• Share Your User Story

Special thanks to CloudBees, Inc. for sponsoring this program.

Jenkins IRC moves to Libera Chat

October 17, 2021, 5:42 am

≫ Next: Four students and their master project in Jenkins security

≪ Previous: New eBook: Jenkins is the Way for IT and software developers

$

0

0

We are happy to announce that the Jenkins community has moved all its official IRC channels to Libera chat. We have started our migration on May 26 as a response to thehostile takeover of hundreds of open source community channel by the new Freenode management. As decided by the Jenkins governance meeting on June 16th, Libera Chat IRC channels are the only official channels going forward.

A more detailed history of the transition is available on the Jenkins developers mailing list.

What did we move?

We have created the following IRC chats:

that currently live on freenode to libera.chat:

• #jenkins - general discussion channel for Jenkins users and developers. We no longer consider it a central chat for all things Jenkins, but we intend to keep it available to users who want to keep using IRC.

• #jenkins-hosting - Chat used by the Hosting Team to manage hosting automation

• #jenkins-infra - Chat used by the Infrastructure Team to coordinate efforts related to Jenkins project infrastructure and the incident response

• #jenkins-release- Chat used for Jenkins core release coordination by the Release Team

All other channels have NOT been moved to Libera Chat IRC and were replaced by other channels. Most notable channels:

• #jenkins-meeting - the Jenkins Governance Meeting uses combination of Zoom and Google Docs at the moment. We do not longer use the IRC chat for that purpose.

• #jenkins-cert - no private chat going forward. The Security Team will use mailing lists only going forward

• #jenkins-community - Replaced by the Advocacy&Outreach Gitter channel.

Freenode concerns and disclaimers

Going forward, the Jenkins community does not have ANY official channels on Freenode. All channels are either removed or left abandoned. We no longer manage or control our channels. Most of the Jenkins IRC channel operators use IRCCloud, and hence they were banned by the Freenode team on June 11th. Only a few operators have reconnected since this event.

Taking the takeover of Freenode and hostile actions taken by the new management, we can no longer guarantee any of the following:

• Authenticity of registered users on Freenode. All IRC accounts, cloaked or not, might have been taken over by the new Freenode management. Do not trust messages from the Jenkins contributor account IDs there.

• Confidentiality of private channels like #jenkins-cert. We performed audit of the conversations there, and we believe there are no undisclosed security vulnerabilities referenced in the channel. After all, this IRC has been rather dormant for the last 18 months.

• IRC User Passwords. All passwords on Freenode IRC may be compromised in the future. We strongly advise all users to rotate their passwords if they were used on Freenode IRC.

We have made backups of IRC channel conversations in the abandoned channels. If you need to access the conversation history, please reach out to the Jenkins Infrastructure team.

Acknowledgements

We thank the entire Libera Chat team and all contributors who have worked on creating a Freenode replacement for hundreds of open source communities using IRC. Within just a month, a new platform has been created and adopted by almost all active projects. We remember the Hudson to Jenkins renaming days when a similar mobilization happened in the Jenkins community, and we appreciate all the effort put by contributors.

Special thanks to Tim Jacomb, Gavin Mogan, Alex Earl, and Olivier Vernin for their work on the migration of IRC channels and our automation like the IRC Bot used by the Jenkins hosting team.

What’s next?

In the Jenkins community we will keep using Libera Chat IRC and maintaining user and contributor channels there. Other Jenkins chat channels like Gitter and Slack are unchanged. We intend to gradually replace many of those channels with community.jenkins.io. This is a new portal powered by Discourse. The service is sponsored by Civilized Discourse Construction Kit, Inc.. It is currently in preview, stay tuned for announcements. As always, we will appreciate any suggestions and [feedback](https://community.jenkins.io/c/site-feedback/2)!

Four students and their master project in Jenkins security

October 17, 2021, 5:42 am

≫ Next: GSoC CDF Meetup: Google Summer of Code Midterm Demos

≪ Previous: Jenkins IRC moves to Libera Chat

$

0

0

Context

Jenkins is a CI/CD solution and as such, it is critical that the open source plugins that constitute an integral part of it don’t expose the systems they are used on to any security risks and vulnerabilities. It is in that context that we worked as an audit/code review team to track and report such flaws and problematic practices.

We worked in collaboration with Jenkins Security team member Wadeck Follonier, as part of an end-of-study project during our last year of the Master’s Degree - Reliability and IT Security in the university of Aix-Marseille.

Project Goals

The main goal of this project was to allow us to discover and work on diverse security vulnerabilities in the context of a widely-used software solution, and in order to achieve that we had to separate the project in multiple other goals:

• Learning about some of the most common vulnerabilities and the form in which they can be found on a Jenkins Instance and its plugins.

• Performing code review and technical audit on the application, and compiling our results as part of a security team.

• Reporting our findings to the Jenkins team and the plugin maintainers, while sometimes helping the latter to correct these vulnerabilities.

Knowledge Sharing

At the beginning of the project, we set up communication channels with our mentor through Slack and Google Meets, and agreed to schedule weekly sessions with him. The goal of these sessions was both to teach us more about the functionalities of Jenkins and the types of vulnerabilities we would encounter, and to allow us to ask more specific questions regarding our findings.

Thanks to our mentor developing a mock plugin compiling a variety of classic vulnerabilities and several of their implementations, including server side request forgery (SSRF), cross site scripting (XSS), and XML external entity (XXE) attacks, we have been able to learn through practice. It allowed us to analyze the context of the code and the different ways the Jelly framework can be used to display information, expanding our payload options and giving us a clearer view of the patterns to look for during our code reviews.

We have also had the opportunity to learn about the process used to report the vulnerabilities to the maintainers through Jira issues, and some ways we could correct them or provide steps to do so.

Searching and compiling

At first, we decided to work as a pretty loose team, with each member working on a different plugin and regrouping our findings to confirm or reject them, while staying in constant contact to ask each other questions. This allowed us to broaden the scope of our searches, and is the reason why we have been able to find a larger number of vulnerabilities, in plugins that differed widely in popularity, than we would have working together from the start.

We used a single file to compile the plugins we audited and our findings, making it easier for our mentor to review them and give us feedback. Pinpointing the specific portion of code causing the issue and providing reproduction steps as clear as we could proved useful for the reporting process, thus making the approval and correction faster.

During the last third of this project, we began to work together on bigger plugins, in order to have more points of view reflecting on the same problem. With different analyses, we were able to come up with new payloads, and sometimes with new vulnerabilities where we only found one separately.

Reporting and correcting the vulnerabilities

All of the reporting was done through Jira issues, which allows the Jenkins team to centralize and triage the vulnerabilities. Once we provided the necessary information, along with the reproduction steps we had, a member of the Jenkins security team contacted the plugin maintainer and guided them through the next steps of the process, with hope that they would answer.

We have also tried to make the maintainers' job easier, working on some fixes. To achieve this, we delved not only into the functionalities of the vulnerable plugins, but also into some mitigation processes that we found either in the Jenkins documentation, or with the help of our mentor.

Each one of our modifications has been tested locally, in order to assess whether the vulnerability was still present, and whether no function had been altered. However, some of the plugins we audited demanded more complex fixes, due to their intrinsic logic, or the thought process of their developer, which led to us being unable to provide a clear fix.

Considering this, the fixes we have been able to bring into light were only suggestions to the maintainers, for them to use as inspiration or template, in order not to interfere with the plugin logic.

Conclusion

Through this project, we have been able to work as a team, delving into some of the different issues that security engineers are bound to face, and the ways they have at their disposal to mitigate them. This has allowed us to complement our studies with a more practical aspect, that we couldn’t have had otherwise, and to transition into the companies we are now interns in. This experience has strongly encouraged us to improve in and document ourselves on this branch of cybersecurity, which will have a significant impact on our professional future.

Useful links

• Jenkins - 2021/03/30 Security Advisory - 5 from us

• Jenkins - 2021/05/11 Security Advisory - 4 from us

• Jenkins - 2021/05/25 Security Advisory - 3 from us

• Jenkins - 2021/06/16 Security Advisory - 1 from us

• Jenkins - 2021/06/18 Security Advisory - 1 from us

Message from the mentor

I didn’t expect to have four students with a so deep desire to learn new things, new tricks. Their curiosity helped them to find numerous vulnerabilities that already led to 14 published CVEs. The experience was great and I wish them all the best for their professional career and their never ending quest for knowledge.

If you are student, intern, or just someone really interested in security and Jenkins in particularly, please reach out to us to see if there is a possibility to organize something together. Mailing list: jenkinsci-cert@googlegroups.com