All the way back at Jenkins World in September, Andrew Bayer presented asneak peak of a new syntax for constructing Pipelines. We are calling this new syntax Declarative Pipeline to differentiate it from the existing Scripted Pipeline syntax that has always been a part of Pipeline.

After listening to many Jenkins users over the last year we felt that, while Pipeline Script provides tremendous power, flexibility, and extensibility, the learning curve for Scripted Pipeline was steep for users new to either Jenkins or Pipeline. Beginning users wanting to take advantage of all the features provided by Pipeline and Jenkinsfiles were required to learn Scripted Pipeline or remain limited to the functionality provided by Freestyle jobs.

Declarative Pipeline does not replace Scripted Pipeline but extends Pipeline it with a pre-defined structure to let users focus entirely on the steps required at each stage without needing to worry about scripting every aspect of the pipeline. Granular flow-control is extremely powerful and Scripted Pipeline syntax will always be part of Pipeline but it’s not for everyone.

Declarative Pipeline enables all users to connect simple, declarative blocks that define build agents (including Docker), post build actions, environment settings, credentials and all stages that make up the pipeline. Best of all, because this Declarative syntax is part of Pipeline, all build steps and build wrappers available in Plugins or loaded from Shared Libraries are also available as steps in Declarative.

Below is an example of a pipeline in Declarative syntax. You can also switch the view to show the same pipeline in Scripted syntax. The Declarative syntax has a more straightforward structure that is easier to grok by users not versed in Groovy.

Blue Ocean is all about Pipelines in Jenkins. Running, displaying, and soon, creating Pipelines. Blue Ocean will be able to run and display Pipelines written in this new syntax just like any other Pipeline works today. However, because Declarative Pipeline includes a pre-defined structure, or model, it is now possible to create and edit pipelines with a GUI editor.

Although we plan to launch 1.0 of Declarative Pipeline before Blue Ocean 1.0 is officially available, we expect to have a working Beta of the Editor available to play with. The combination of a simple syntax and an intuitive editor should make creating Jenkisn Pipelines a breeze.

I hope everyone has a great end of the year and a Happy New Year. With Declarative Pipeline andBlue Ocean we expect great things for Jenkins in 2017!

The Puppet Enterprise for Jenkins Pipeline plugin itself has zero system dependencies. You need only to install the plugin from the update center. The plugin uses APIs available in Puppet Enterprise to do its work. Since the PuppetDB query, Code Management, and Orchestrator APIs are all backed by Puppet Enterprise’s role-based access control (RBAC) system, it’s easy to restrict what pipelines are allowed to control in Puppet Enterprise. To learn more about RBAC in Puppet Enterprise, read the docs here.

Configuring the plugin is fairly straight forward. It takes three simple steps:

PuppetDB is an extensive data store that holds every bit of information Puppet generates and collects across every system Puppet is installed on. PuppetDB provides a sweet query language calledPQL. With PQL, you can ask complex questions of your infrastructure such as "How many production Red Hat systems are there with the openssl package installed?" or "What us-west-2c nodes with the MyApp role that were created in the last 24 hours?"

This can be a powerful tool for parts of your pipeline where you need to perform specific operations on subsets of the infrastructure like draining a loadbalancer.

Here’s an example using the puppet.query method:

The query returns an array of matching items. The results can be iterated on, and even passed to a series of puppet.job calls. For example, the following code will query all nodes in production that experienced a failure on the last Puppet run.

Note that once you can use closures in Pipeline scripts, doing the above example will be much simpler.

The orchestration service in Puppet Enterprise is a tool to perform orchestrated Puppet runs across as broad or as targeted an infrastructure as you need at different parts of a pipeline. You can use the orchestrator to update applications in an environment, or update a specific list of nodes, or update nodes across a set of nodes that match certain criteria. In each scenario, Puppet will always push distributed changes in the correct order by respecting the cross-node dependencies.

To create a job in the Puppet orchestrator from a Jenkins pipeline, use thepuppet.job method. The puppet.job method will create a new orchestrator job, monitor the job for completion, and determine if any Puppet runs failed. If there were failures, the pipeline will fail.

The following are just some examples of how to run Puppet orchestration jobs against the infrastructure you need to target.

Target an entire environment:

Target instances of an application in production:

Target a specific list of nodes:

Target nodes matching a complex set if criteria:

As you can see, the puppet.job command means you can be as broad or as targeted as you need to be for different parts of your pipeline. There are many other options you can add to the puppet.job method call, such as setting the Puppet runs to noop, or giving the orchestrator a maximum concurrency limit.Learn more about the orchestrator here.

If you’re using Code Management in Puppet Enterprise (and you should), you can ensure that all the modules, site manifests, Hiera data, and roles and profiles are staged, synced, and ready across all your Puppet masters, direct from your Jenkins pipeline.

To update Puppet code across all Puppet masters, use the puppet.codeDeploy method:

Learn more Code Management in Puppet Enterprise here.

The plugin includes an experimental feature to set Hiera key/value pairs. There are many cases where you need to promote information through a pipeline, such as a build version or artifact location. Doing so is very difficult in Puppet, since data promotion almost always involves changing Hiera files and committing to version control.

The plugin exposes an HTTP API endpoint that Hiera can query using the hiera-http backend. With the backend configured on the Puppet master(s), key/value pairs can be set to scopes. A scope is arbitrary and can be anything you like, such as a Puppet environment, a node’s certname, or the name of a Facter fact like operatingsystem or domain.

To set a Hiera value from a pipeline, use the puppet.hiera method.

Now you can set the same key with the same value to the production scope later in the pipeline, followed by a call to puppet.job to push the change out.

Theplugin’s Github repository contains a set of example Pipeline scripts. Feel free to issue pull requests to add your own scripts!

I’m pretty excited to see how this is going to help simplify continuous delivery pipelines. I encourage everyone to get started with continuous delivery today, even if it’s just a simple pipeline. As your practices evolve, you can begin to add automated tests, automate away manual checkpoints, start to incorporate InfoSec tests, and include phases for practices like patch management that require lots of manual approvals, verifications and rollouts. You’ll be glad you did.

Through the course of 2016, the Jenkins project published 16LTS releases and 54Weekly releases. Of those 70 releases, the most notable may have been theJenkins 2.0 release which was published in April.

Jenkins 2 made Pipeline as Code front-and-center in the user experience, introduced a new "Getting Started" experience, and included a number of other small UI improvements, all while maintaining backwards compatibility with existing Jenkins environments.

Since April, we have released a number of LTS releases using Jenkins 2 as a baseline, meaning the Jenkins project no longer maintains any 1.x release lines.

ThePipeline efforts have continuted to gain steam since April, covered on this blog with a number ofposts tagged "pipeline". Closing out 2016 with the announcement of the beta forDeclarative Pipeline syntax which is expected in early 2017.

Hot on the heels of Jenkins 2 announcementBlue Ocean, a new user experience for Jenkins, wasopen sourced in May. Blue Ocean is a new project that rethinks the user experience of Jenkins. Designed from the ground up for Jenkins Pipeline and compatible with Freestyle jobs. The goal for the project is to reduce clutter and increase clarity for every member of a team using Jenkins.

The Blue Ocean beta can be installed from the Update Center and can be run in production Jenkins environments alongside the existing UI. It adds the new user experience under/blue in the environment but does not disturb the existing UI.

Blue Ocean is expected to reach "1.0" in the first half of 2017.

Also in May of 2016, the Jenkins project announced an excitingPartnership with Microsoft to run our project infrastructure onAzure. While the migration of Jenkins project infrastructure into Azure is still on-going, there have been some notable milestones reached already:

The migration to Azure is expected to complete in 2017.

For the first time in the history of the project, Jenkins was accepted intoGoogle Summer of Code 2016. Google Summer of Code (GSoC) is an annual, international, program which encourages college-aged students to participate with open source projects during the summer break between classes. Students accepted into the program receive a stipend, paid by Google, to work well-defined projects to improve or enhance the Jenkins project.

In exchange, numerous Jenkins community members volunteered as "mentors" for students to help integrate them into the open source community and succeed in completing their summer projects.

A lot was learned during the summer which we look forward to applying to Google Summer of Code 2017

In September, over one thousand people attendedJenkins World, in Santa Clara, California.

Following the event,Liam posted a series of blog posts which highlight some of the fantastic content shared by Jenkins users and contributors from around the world, such as:

Jenkins World was the first global event of its kind for Jenkins, it brought users and contributors together to exchange ideas on the current state of the project, celebrate accomplishments of the past year, and look ahead at all the exiting enhancements coming down the pipe(line).

It was such a smashing success thatJenkins World 2017 is already scheduled for August 30-31st in San Francisco, California.

Finally, 2016 saw tremendous growth in the number ofJenkins Area Meetups (JAMs) hosted around the world. JAMs are local meetups intended to bring Jenkins users and contributors together for socializing and learning. JAMs are organized by local Jenkins community members who have a passion for sharing new Jenkins concepts, patterns and tools.

Driven by current Jenkins Events Officer,Alyssa Tong, and the dozens of passionate organizers, JAMs have become a great way to meet other Jenkins users near you.

While we don’t yet have JAMs on each of the seven continents, you can always join the Jenkins Online Meetup. Though we’re hoping more groups will be founded near you in 2017!

I am personally grateful for the variety and volume of contributions made by thousands of people to the Jenkins project this year. I believe I can speak for project founder,Kohsuke Kawaguchi, in stating that the Jenkins community has grown beyond our anything we could have imagined five years ago, let alone ten!

There are number of ways toparticipate in the Jenkins project, so if you didn’t have an opportunity to join in during 2016, we hope to see you next year!

While we may still add more functionality to the Declarative Pipeline syntax, we won’t be making any changes to existing syntax for the 1.0 release. This means that any pipelines you write against the 0.8.1 syntax will keep working for the foreseeable future without any changes. So if you’re already using Declarative Pipelines, make sure to update your `Jenkinsfile`s after upgrading to 0.8.1, and if you haven’t been using Declarative Pipelines yet, install the Pipeline: Model Definition plugin and give them a try!

Way back in September 2013 we announced theLiterate plugin, as an experimental new way of modeling branch development in Jenkins.

When you are performing an experiment, the recommendation is to do just enough work to let you perform the test. However, the culture in Jenkins is to always try and produce reusable components that others can use in ways you have not anticipated.

So when releasing the initial version of theLiterate plugin we also separated the Literate specific bits from the SCM specific concepts and multi-branch concepts. These were lower level concepts were organized into the following plugins:

In addition, we released updates to three of the more common SCM plugins which included implementations of the SCM API:

While there was some interest in the Literate plugin, it did not gain much traction - there are only 39 Jenkins instances running the Literate plugin as of December 2016.

In terms of the reusable components, we had only made a minimal implementation with some limitations:

Roll forward to November 2015 and Jenkins Pipeline got a release of thePipeline Multibranch. It seems that pairing Pipeline with Branch API style multi-branch is much more successful than Literate - there are close to 60,000 instances running the pipeline multi-branch plugin as of December 2016.

There also were two new SCM plugins implementing the SCM API:

Unlike the previous implementations of the SCM API, however, these plugins do not maintain a local cache of the repository state. Rather they make queries via the GitHub / BitBucket REST APIs on demand.

The above design decision exposed one of the initial MVP compromises of the SCM API plugin: very basic event support. Under the SCM API 1.x model, the only event that an SCMSource can signal is something changed, go look at everything again. When you are accessing an API that only allows 5,000 API calls per hour, performing a full scan of the entire repository just to pick up a change in one branch does not make optimum usage of that 5,000 calls/hour rate limit.

So we decided that perhaps the SCM API and Branch API plugins have left their Minimum Viability Experiment state and the corresponding limitations should be addressed.

So what has changed in theSCM API 2.0.x andBranch API 2.0.x release lines? These plugin releases include:

In addition, we have upgraded the following plugins to include the new fine-grained event support:

Ok, that was the good news. Here is the bad news.

We found out that the GitHub Branch Source and BitBucket Branch Source plugins had made invalid assumptions about how to implement the SCM API. To be clear, this was not the plugin developers fault: at the time there was no documentation on how to implement the SCM API.

But fixing the issues that we found means that you have to be careful about which specific combinations of plugin versions you have installed.

Upgrading should make multi-branch projects much better. When you are ready to upgrade you must ensure that you upgrade all the required plugins. If you miss some, just upgrade them and restart to fix the issue.

Other plugins that may require updating:

After an upgrade you will see the data migration warning

SCM API 2.0.x adds fine-grained event support. This should significantly improve the responsiveness of multi-branch projects. This should significantly reduce your GitHub API rate limit usage.

If you are using theGitHub Branch Source orGitHub Organization Folders plugins then upgrading will significantly reduce the API calls made by Jenkins to GitHub.

If you are using any of the upgraded SCM plugins (e.g. Git, Mercurial, GitHub Branch Source, BitBucket Branch Source) then upgrading will significantly improve the responsiveness to push event notifications.

You should read the newdocumentation on how plugin developers are supposed to implement the SCM API

The persistent reader may be wondering what happens now to the Literate plugin.

For me, the logical heir of the Literate Plugin is thePipeline Model Definition plugin. This new plugin has the advantage of an easy to read pipeline syntax with the extra functionality that I suspect was preventing people from adopting Literate.

The good news is that the Pipeline Model Definition already has 5000 installations as of December 2016 and I expect up-take to keep on growing.

Here is how we plan to roll that baseline upgrade in the next few months.

Balancing those numbers with many other criteria:

If you have questions or feedback about this announcement, please feel free to post it to the Jenkins developers mailing list.

With all the new developments inJenkins Pipeline (andDeclarative Pipeline on the horizon), it’s easy to forget what we did to create "pipelines" before Pipeline. There are number of plugins, some that have been around since the very beginning, that enable users to create "pipelines" in Jenkins. For example, basic job chaining worked well in many cases, and theParameterized Trigger plugin made chaining more flexible. However, creating chained jobs with conditional behavior was still one of the harder things to do in Jenkins.

TheConditional BuildStep plugin is a powerful tool that has allowed Jenkins users to write Jenkins jobs with complex conditional logic. In this post, we’ll take a look at how we might converting Freestyle jobs that include conditional build steps to Jenkins Pipeline. Unlike Freestyle jobs, implementing conditional operations in Jenkins Pipeline is trivial, but matching the behavior of complex conditional build steps will require a bit more care.

The Conditional BuildStep plugin lets users add conditional logic to Freestyle jobs from within the Jenkins web UI. It does this by:

In the example below, this project will run the shell script step when the value of theREQUESTED_ACTION token equals "greeting".

Here’s the output when I run this project with REQUESTED_ACTION set to "greeting":

And when I pass the value "silence":

This is a simple example but the conditional step can contain any regular build step. When combined with other plugins, it can control whether to send notifications, gather data from other sources, wait for user feedback, or call other projects.

The Conditional BuildStep plugin does a great job of leveraging strengths of the Jenkins web UI, Freestyle jobs, and UI-based programming, but it is also hampered by their limitations. The Jenkins web UI can be clunky and confusing at times. Like the steps in any Freestyle job, these conditional steps are only stored and viewable in Jenkins. They are not versioned with other product or build code and can’t be code reviewed. Like any number of UI-based programming tools, it has to make trade-offs between clarity and flexibility: more options or clearer presentation. There’s only so much space on the screen.

Jenkins Pipeline, on the other hand, enables users to implement their pipeline as code. Pipeline code can be written directly in the Jenkins Web UI or in any text editor. It is a full-featured programming language, which gives users access to much broader set of conditional statements without the restrictions of UI-based programming.

So, taking the example above, the Pipeline equivalent is:

When I run this project with REQUESTED_ACTION set to "greeting", here’s the output:

When I pass the value "silence", the only change is "Hello, bitwiseman!" is not printed.

Some might argue that the Pipeline code is a bit harder to understand on first reading. Others would say the UI is just as confusing if not more so. Either way, the Pipeline representation is considerably more compact than the Jenkins UI presentation. Pipeline also lets us add helpful comments, which we can’t do in the Freestyle UI. And we can easily put this Pipeline in a Jenkinsfile to be code-reviewed, checked-in, and versioned along with the rest of our code.

Let’s do one more example that shows some of these conditions and tokens. This time we’ll perform different build steps depending on what branch we’re building. We’ll take two build parameters: BRANCH_PATTERN and FORCE_FULL_BUILD. Based on BRANCH_PATTERN, we’ll checkout a repository. If we’re building on the master branch or the user checked FORCE_FULL_BUILD, we’ll call three other builds in parallel (full-build-linux, full-build-mac, and full-build-windows), wait for them to finish, and report the result. If we’re not building on the master branch and the user did not check FORCE_FULL_BUILD, we’ll print a message saying we skipped the full builds.

As I said before, the Conditional BuildStep plugin is great. It provides a clear, easy to understand way to add conditional logic to any Freestyle job. Before Pipeline, it was one of the few plugins to do this and it remains one of the most popular plugins. Now that we have Pipeline, we can implement conditional logic directly in code.

This is blog post discussed how to approach converting conditional build steps to Pipeline and showed a couple concrete examples. Overall, I’m pleased with the results so far. I found scenarios which could not easily be migrated to Pipeline, but even those are only more difficult, rather than impossible.

The next thing to do is add a section to theJenkins Handbook documenting the Pipeline equivalent of all of the Conditions and the most commonly used Tokens. Look for it soon!

You would know this if you followedThorsten’s twitter account.

That twitter account is mostly pics of Thorsten in running gear, but occasionally he announces new features as they land.

When you run a pipeline that requires parameters, it will popup a dialog like this no matter where you run it from. Most input types are supported (similar to input), with a planned extension point for custom input types.

Currently this is hidden behind afeature toggle, to access append ?blueCreate to the URL in you browser, and then press the "New Pipeline" button. Currently it lets you quickly create a Pipeline from Git, add credentials, etc, in a very nice UX. More SCM types are being added to support this.

As Blue Ocean is a very "live" style of UX, if your network becomes unavailable, or the server is restarted, it is good to know in case you were staring at the screen waiting for something to happen (don’t you have anything better to do??). When this happens, now you get a polite message, and then when the connection is restored, even if you are waiting for a Pipeline run to finish, it will then notice this, and refresh things for you:

Note the opacity changes to make it clear even if you don’t see the little message. Very nice addition for those of us who work on a train far to often.

What is up next:

There was also a couple of "alternative beta" releases in the "Experimental Update Center" to help test the new SCM API improvements for better use of GitHub APIs (based onthis branch) I do not recommend trying this branch unless you know what you are doing, as this will migrate some data, but help testing it would be appreciated!

Enjoy!

If you’re interested in helping to make Blue Ocean a great user experience for Jenkins, please join the Blue Ocean development team on Gitter!

To understand Pipeline behavior you must understand a few points about how it executes.

From these we arrive at a set of best practices to make pipelines more effective.

Please, think of these as guidelines, not strict rules – Jenkins Pipeline provides a great deal of power and flexibility, and it’s there to be used.

Breaking enough of these rules at scale can cause masters to fail by placing an unsustainable load on them.

For additional guidance, I also recommendthis Jenkins World talk on how to engineer Pipelines for speed and performance:

To assist with Pipeline development, here are common serializable and non-serializable types, to assist with deciding if your logic can be CPS or should be in a @NonCPS function to avoid issues.

Common Serializable Types (safe everywhere):

Common non-Serializable Types (only safe in @NonCPS functions):

Pipeline as Code was one of the pillars of the Jenkins 2.0 release and an essential part of implementing continuous delivery (CD). Defining all of the stages of an application’s CD pipeline within a Jenkinsfile and checking it into the repository with the application code provides all of the benefits inherent in source control management (SCM):

We recommend people begin using it for all their Pipeline definitions in Jenkins. The plugin has been available for use and testing starting with the 0.1 release that was debuted atJenkins World in September. Since then, it has already been installed in over 5,000 Jenkins environments.

If you haven’t tried Pipeline or have considered Pipeline in the past, I believe this new syntax is much more approachable with an easier adoption curve to quickly realize all of the benefits of Pipeline as Code. In addition, the pre-defined structure of Declarative makes it possible to create and edit Pipelines with a graphical user interface (GUI). The Blue Ocean team is actively working on a Visual Pipeline Editor which will be included in an upcoming release.

If you have already begun using Pipelines in Jenkins, I believe that this new alternative syntax can help expand that usage.

The original syntax for defining Pipelines in Jenkins is a Groovy DSL that allows most of the features of fullimperative programming.

This syntax is still fully supported and is now referred to as "Scripted Pipeline Syntax" to distinguish it from "Declarative Pipeline Syntax." Both use the same underlying execution engine in Jenkins and both will generate the same results inPipeline Stage View or Blue Ocean visualizations. All existingPipeline steps, Global Variables, andShared Libraries can be used in either. You can now create more cookie-cutter Pipelines and extend the power of Pipeline to all users regardless of Groovy expertise.

Be on the lookout for future blog posts detailing specific examples of scenarios or features in Declarative Pipeline. Andrew Bayer, one of the primary developers behind Declarative Pipeline, will be presenting atFOSDEM in Brussels, Belgium this weekend. We have also scheduled an onlineJenkins Meetup (JAM) later this month to demo the features of Declarative Pipeline and give a sneak peek at the upcoming Blue Ocean Pipeline Editor.

In the meantime, all thePipeline documentation has been updated to incorporate aGuided Tour, and aSyntax Reference with numerous examples to help you get on your way to using Pipeline. Simply upgrade to the latest version, 2.5 or later of the Pipeline in Jenkins to enable all of these great features.

Upgrading should make multi-branch projects much better. When you are ready to upgrade you must ensure that you upgrade all the required plugins. If you miss some, just upgrade them and restart to fix the issue. And of course, it’s always a good idea to take a backup of your JENKINS_HOME before upgrading any plugins.

In the list below, version numbers in bold indicate a change from the original version in theoriginal announcement

If you are using the Blue Ocean plugin

Other plugins that may require updating:

After an upgrade you will see the data migration warning (see the screenshot inJENKINS-41608 for an example) this is normal and expected. The unreadable data will be removed by the next scan / index or can be removed manually using the Discard Unreadable Data button. The warning will disappear on the next restart after the unreadable data has been removed.

Please update to the versions listed above. If you want to know more about the issues and how they were resolved, see the next section.

The issues described below are resolved with these plugin releases:

JENKINS-41121: GitHub Branch Source upgrade can cause a lot of rebuilds:

Migration of GitHub branches from 1.x to 2.x resulted in a change of the implementation class used to identify branches. Some other other bugs in Branch API had been fixed and the combined effect resulted in a rebuild of all GitHub Branches (not PRs) after an upgrade to GitHub Branch Source Plugin 2.0.0. This rebuild was referred to as a "build storm".

Resolution:

JENKINS-41255: Upgrading from a navigator that did not assign consistent source ids to a version that does assign consistent source ids causes a build storm on first scan:

The GitHub Branch Source and BitBucket Branch Source plugins in 1.x were not assigning consistent IDs to multi-branch projects discovered in an Organization Folder. Both plugins were fixed in 2.0.0 to assign consistent IDs as a change of ID would result in a rebuild of all projects. What was missed is that the very first scan of an Organization Folder after an upgrade will change the randomly assigned ID assigned by the 1.x plugins into the consistent ID assigned by the 2.0.0 plugins and consequently trigger a rebuild of all branches. This rebuild was referred to as a "build storm".

Resolution:

The Branch API plugin was enhanced to detect the case where a branch source has been changed but the change is only changing the ID. When such changes are identified, the downstream references of the ID are all updated which will prevent a build storm.

JENKINS-41313: On first index after upgrade to 2.0.0 all open PRs are rebuilt:

The BitBucket Branch Source 1.x did not store all the information about PRs that is required by the SCM API 2.0.x model. This could well have resulted in subtle effects when manually triggering a rebuild of a merge PR if the PR’s target branch has been modified after the PR branch was first detected by Jenkins. Consequently, as the information is required, BitBucket Branch Source plugin 2.0.0 populated the information with dummy values which would force the correct information to be retrieved. The side-effect is that all PR branches would be rebuilt.

Resolution:

JENKINS-41124: Can’t get a human readable job name anymore:

During initial testing of the Branch API 2.0.0 release an issue was identified with how Organization Folders handled unusual names. None of the existing implementations of the SCMNavigator API could generate such unusual names due to form validation on GitHub / BitBucket replacing unusual characters with - when creating a repository.

It would be irresponsible to rely on external services sanitizing their input data for the correct operation of Organization Folders. Consequently, in Branch API 2.0.0 the names were all transformed into URL safe names, with the original URLs still resolving to the original projects so that any existing saved links would remain functional.

Quite a number of people objected to this change of URL scheme.

Resolution:

Side-effect:

This means that the Jenkins Item rename API cannot be used.

At this time, the only known side-effect is in the Job Configuration History plugin. The configuration history of each child item will still be tracked going forward after the upgrade. The pre-upgrade configuration history is also retained. Because the Jenkins Item rename API cannot be used to flag the configuration file location change, there is no association between the pre-upgrade history chain and the post-upgrade history chain.

As a mentor, you will be asked to:

Mentorship does not require strong expertise in Jenkins plugin development. The main objective is to guide students and to get them involved into the Jenkins community. If your mentor team requires any specific expertise, GSoC org admins will do their best in order to find advisors.

You are:

Your project idea is:

If you are interested, drop the Email to the Jenkins Developer mailing list with the GSoC2017 prefix.