Welcome Ewelina Wilkosz - new Jenkins Governance Board member

November 11, 2021, 7:12 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!

November 11, 2021, 7:12 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!

November 11, 2021, 7:12 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

November 11, 2021, 7:12 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

November 11, 2021, 7:12 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

November 11, 2021, 7:12 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!)

November 11, 2021, 7:12 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

November 11, 2021, 7:12 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

November 11, 2021, 7:12 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!

Four students and their master project in Jenkins security

November 11, 2021, 7:12 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

GSoC CDF Meetup: Google Summer of Code Midterm Demos

November 11, 2021, 7:12 am

≫ Next: Git username / password credentials binding

≪ Previous: Four students and their master project in Jenkins security

$

0

0

Congratulations to all GSoC students who have made it through the first half of the GSoC 2021 coding phase!

This year, the Jenkins project has been participating in GSoC as part of the Continuous Delivery Foundation’s GSoC org. To celebrate our GSoC students and the fantastic work they have been doing, the CDF is hosting an online meetup where students will present their work. Students will be showcasing what they have learned and accomplished thus far in GSoC, demoing their work, and discussing their goals and plans for the second coding phase.

The CDF Google Summer of Code Midterm Demos will be held online on July 20th, 13:00 UTC - 15:00 UTC.

Sign up here: Meetup Event

Speakers

Akihiro Kiuchi - Jenkins Remoting Monitoring

Akihiro is a student in the Department of information and communication engineering at the University of Tokyo. He is improving the monitoring experience of Jenkins Remoting during Google Summer of Code 2021.

• Affiliation: The University of Tokyo and Jenkins project

• GitHub: Aki-7

Title: Jenkins Remoting Monitoring with OpenTelemetry

In this talk, he will discuss the problems in maintaining Jenkins agents and how to support Jenkins admins in troubleshooting them. As one of the solutions, he will introduce the new Remoting monitoring with OpenTelemetry plugin that collects Jenkins Remoting monitoring data and troubleshooting data using OpenTelemetry. What kind of data the plugin will collect and how we will be able to visualize them using available open-source monitoring tools will be demonstrated.

Shruti Chaturvedi - CloudEvents Plugin for Jenkins

Shruti is an undergrad student of Computer Science at Kalamazoo College. She is developing a CloudEvents integration for Jenkins, allowing other CloudEvents-compliant CI/CD tools to communicate easily. Shruti is also the Founding Engineer of a California-based startup, MeetKlara, where she is building serverless solutions and advocating for developing CI/CD pipelines using open-source tools.

• Affiliation: Kalamazoo College and Jenkins project

• GitHub: ShrutiC-git

• LinkedIn: Shruti Chaturvedi

Title: CloudEvents Plugin for Jenkins: Moving Towards Interoperability

In this talk, we will look at interoperability as an essential element in building workloads across several services. We will also talk about how CloudEvents solves one of the biggest challenges in achieving interoperability between systems: lack of normalization/standardization. Without any standard definition, in order to achieve interoperability, services have to develop adapters specific to a particular system. That, however, is complex because services are always changing the way data/events are emitted. CloudEvents solves this problem by defining a standard format for events, which can be emitted/consumed agnostically, thereby achieving indirect interoperability. Shruti will demonstrate the workings of CloudEvents Plugin for Jenkins; she will walk us through how Jenkins can be configured as a source and a sink, emitting and consuming CloudEvents-compliant events in a platform-independent manner.

Daniel Ko - try.spinnaker.io

Daniel is studying computer science at the University of Wisconsin - Madison. He is developing a public Spinnaker sandbox environment for Google Summer of Code 2021.

• Affiliation: University of Wisconsin - Madison and Spinnaker project

• GitHub: ko28

Title: try.spinnaker.io: Explore Spinnaker in a Sandbox Environment!

The talk will go through a brief explanation of Spinnaker and the challenges that users face during the installation process. He will discuss the infrastructure of this project and how a public multi tenant spinnaker instance will be managed and installed. We will end with a demo of the site so far and the various features implemented, including Github authentication, K8s manifest deployment, AWS Load Balancer Controller to expose deployments, private ECR registry and the blocking of all public images, and auto resource cleanup.

Aditya Srivastava - Conventional Commits Plugin for Jenkins

Aditya is a curiosity driven individual striving to find ingenious solutions to real-world problems. He is an open-source enthusiast and a lifelong learner. Aditya is also the Co-Founder and Maintainer of an Open Source Organization - Auto-DL, where he’s leading the development of a Deep Learning Platform as a Service application.

• Affiliation: V.E.S.I.T & Jenkins project

• GitHub: ADI10HERO

• LinkedIn: Aditya S.

Title: Conventional Commits Plugin for Jenkins

In this talk, we’ll start with what are conventional commits and why they are needed. Then we’ll see what the jenkins plugin, "Conventional Commits" is and what goal it is trying to achieve. A demo of how the plugin can be used/integrated in the current workflow will be shown. Finally, we’ll talk about the next steps in plugin development followed by the QnA.

Harshit Chopra - Git credentials binding for sh, bat, and powershell

Harshit Chopra is a recent graduate and is currently working on a Jenkins project which brings the authentication support for cli git commands in a pipeline job and freestyle project.

• Affiliation: Punjab University & Jenkins Project

• GitHub: link: arpoch

• LinkedIn: Harshit Chopra

• Website

Title: Git credentials binding for sh, bat, and powershell

In this talk, he will give an overview of the project and will move on further explaining what problems are being faced, a bit about the workaround that are being used to tackle the problems, what makes the authentication support so important, why a feature and not a plugin in itself, accomplishments achieved and work done during the coding phase 1, will talk about the implementation of the feature, demonstration of git authentication support over HTTP protocol.

Pulkit Sharma - Security Validator for Jenkins Kubernetes Operator

Pulkit is a student at Indian Institute of Technology,BHU,Varanasi. He is working on a GSoC Project under Jenkins where he aims to add a security validator to the Jenkins Kubernetes Operator.

• Affiliation: Indian Institute of Technology, BHU and Jenkins Project.

• GitHub: sharmapulkit04

Title: Security Validator for Jenkins Kubernetes Operator

In this talk, we will discuss why we need a security validator for the Jenkins Kubernetes Operator and how we are going to implement it via admission webhooks. We will have a look at how we are going to implement the validation webhook, the validation logic being used and what tools we are using to achieve it. Pulkit will showcase his progress and will discuss his future plans for phase 2 and beyond as well.

Git username / password credentials binding

November 11, 2021, 7:12 am

≫ Next: Introducing the Conventional Commits Plugin for Jenkins

≪ Previous: GSoC CDF Meetup: Google Summer of Code Midterm Demos

$

0

0

Google Summer of Code 2021 is implementing git credentials binding for sh, bat, and powershell. Git credentials binding is one of the most requested features for Jenkins Pipeline (see JENKINS-28335).

The project involves extending the Credentials Binding Plugin to create custom bindings for two types of credentials essential to establish a remote connection with a git repository

• Username/Password

• SSH Private Key

Why use git credentials binding?

Many operations in a Jenkins Pipeline or Freestyle job can benefit from authenticated access to git repositories. Authenticated access to a git repository allows a Jenkins job to

• apply a tag and push the tag

• merge a commit and push the merge

• update submodules from private repositories

• retrieve large files with git LFS

The git credentials username / password binding included in git plugin 4.8.0 allows Pipeline and Freestyle jobs to use command line git from sh, bat, and powershell for authenticated access to git repositories.

How to use git credentials binding?

The binding is accessible using the withCredentials Pipeline step. It requires two parameters:

credentialsId

Reference id provided by creating a Username/Password type credential in the Jenkins configuration. To understand how to configure credentials in a Jenkins environment: Using Credentials

gitToolName

Name of the git installation in the machine running the Jenkins instance (Check Global Tool Configuration section in Jenkins UI)

Note: In case a user is not aware of the git tool installation of the particular machine, the default git installation will be chosen.

Examples

The withCredentials wrapper allows declarative and scripted Pipeline jobs to perform authenticated command line git operations with sh, bat, and powershell tasks.

Shell example

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) {
  sh 'git fetch --all'
}

Batch example

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) {
  bat 'git submodule update --init --recursive'
}

Powershell example

withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id', gitToolName: 'git-tool')]) {
  powershell 'git push'
}

The Pipeline Syntax Snippet Generator is a good way to explore the syntax of the withCredentials step and the git username / password credentials binding.

Limitations

The git credentials username / password binding has been tested on command line git versions 1.8.3 through 2.32.0. It has been tested on CentOS 7, CentOS 8, Debian 9, Debian 10, FreeBSD 12, OpenBSD 6.9, openSUSE 15.2, Ubuntu 18.04, Ubuntu 20.04, Ubuntu 21.04, and Windows 10. Processor testing has included amd64, arm32, arm64, and s390x.

The binding does not support private key credentials. The binding is not supported on command line git versions prior to 1.8.3.

What’s next?

Private key credentials support is coming soon.

Introducing the Conventional Commits Plugin for Jenkins

November 11, 2021, 7:12 am

≫ Next: Remoting Monitoring with OpenTelemetry - Coding Phase 1

≪ Previous: Git username / password credentials binding

$

0

0

The conventional commits plugin is a Google Summer of Code project. Special thanks to the mentors Gareth Evans, Kristin Whetstone, Olivier Vernin and Allan Burdajewicz.

What are Conventional Commits

According to the official website, conventonal commits are, "A specification for adding human and machine readable meaning to commit messages."

Conventional commits are a lightweight convention on top of commit messages.

The following table shows major structural elements offered by the conventional commits convention.

Why Conventional Commits

As the CI/CD world is moving more towards complete automation and minimal human interaction, the ability to fully automate a release is desired. Conventional Commits enable the use of automated systems on top of commit messages. These systems can "truly" automate a release with almost no human interaction.

The convention dovetails with semantic versioning. Let’s take an example, a maven project is currently versioned at 1.2.0. The following table shows how conventional commits would bump the version depending on the type of the commit.

Structural Element	Example
Chore	chore: improve logging
Fix	fix: minor bug fix
Feat	feat: add a new feature
Breaking Change	BREAKING CHANGE: reimplement

The Conventional Commits Plugin

The conventional commits plugin is a Jenkins plugin to programatically determine the next semantic version of a git repository using:

• Last tagged version

• Commit message log

• Current version of the project

How it works?

The plugin will read the commit messages from the latest tag or the current version of the project till the latest commit. Using this information it will determine what would be the next semantic Version for that particular project.

Supported Project Types?

Currently the plugin can read the current version from various configuration files of the following project types:

Commit Message	Version Bump	SemVer Equivalent
chore: improve logging	1.2.0→ 1.2.0	No version bump
fix: minor bug fix	1.2.0→ 1.2.1	Increment in the patch version
feat: add a new feature	1.2.0→ 1.3.0	Increment in the minor version
BREAKING CHANGE: reimplement	1.2.0→ 2.0.0	Increment in the major version

How to request a project type support?

Please feel free to open an issue on the GitHub repository of the plugin.

Project Type	Configuration File(s) Read
Maven	pom.xml
Gradle	build.gradle
Make	Makefile
Python	setup.py setup.cfg pyproject.toml
Helm	Charts.yml
Node (NPM)	package.json

How to use the plugin

Recommended way of using the plugin is to add a step in a Jenkins Pipeline Project.

nextVersion() is the pipeline step to be used.

For example:

pipeline {
    agent any

    environment {
        NEXT_VERSION = nextVersion()
    }

    stages {
        stage('Hello') {
            steps {
                echo "next version = ${NEXT_VERSION}"
            }
        }
    }
}

Tip: The pipeline step can also be generated with the help of the Snippet Generator.Please select "nextVersion" in the Sample Step drop down and then click on "Generate Pipeline Snippet"

The plugin is released on every feature using JEP-229.

The plugin is available to download from the plugins site.

Demo

You can watch the plugin in action in a demo presented at the GSoC Midterm Presentations

Next Steps

• Support for pre-release information. Example: 1.0.0-alpha, 1.0.0-beta, etc

• Support for build metadata. Example: 1.0.0-beta+exp.sha.5114f85

• Optionally writing the calcuated "Next Version" into the project’s configuration file. Example: pom.xml for a maven project, setup.py for python.

Feedback

We would love to hear your feedback & suggestions for the plugin.

Please reach out on the plugin’s GitHub repository, the Gitter channel or start a discussion on community.jenkins.io.