Jenkins multibranch pipeline projects with Plastic GitServer

Tuesday, October 11, 2016 0 Comments

The goal of this blog post is to explain how you can take advantage of the Jenkins pipeline projects with Plastic. As you probably know, Plastic SCM already includes a plugin for regular Jenkins projects. This way each of your commits/checkins will trigger a build in Jenkins. But the standard plugin does not yet support the Jenkins Pipelines (formerly called "workflows"). Jenkins supports Pipelines with Git, though, so we will use Plastic GitServer to take advantage of that.

Pipelines are Jenkins jobs enabled by the Pipeline plugin and built with simple text scripts that use a Pipeline DSL (domain-specific language) based on the Groovy programming language.

Pipelines leverage the power of multiple steps to execute both simple and complex tasks according to parameters that you establish. Once created, pipelines can build code and orchestrate the work required to drive applications from commit to delivery.

The concept of build pipelines has been around for a few years and it is now becoming more and more a standard practice.

Configure your Plastic SCM server as a Git server

You need to configure your Plastic SCM server to serve repositories using the Git protocol.

We call this feature GitServer and you can read all about it here.

Plastic GitServer allows any tool in the Git ecosystem to connect directly to Plastic SCM using the native Git functionalities.

Different parameters can be customized as the mapping interval (how often GitServer looks for new changes in Plastic SCM).

We will be using the Git support for Pipeline projects in Jenkins but we will not be using a standard Git server, but our Plastic SCM server behaving like a Git server.

Configure the multibranch Pipeline project in Jenkins

Once we have enabled Plastic GitServer, we can configure the multibranch pipeline project using the Git plugin.

For that purpose, we go to “New project” -> “Multibranch Pipeline” project:

After that, we need to enter our project name, our Plastic SCM repo (using the Git format) and some other project settings. I will be using an instructional repository based on: https://github.com/kishorebhatia/pipeline-as-code-demo.

Please check how we are accessing our Plastic Server as “git://localhost/pipeline-as-code-demo” through the Git proto.

Finally, we save the project settings. Now we can check how the different repository branches are indexed.

Triggering Jenkins builds based on the changes performed in our Plastic SCM repo

Following our development workflow, I’m going to perform some changes in my “SCM003” and “SCM004” task branches. We can see how the pipeline Jenkins project is able to detect the changes triggering the builds. As I have only performed changes on “SCM003” and “SCM004”, Jenkins schedules a build only for these branches.

If we navigate through the different changes in the Jenkins build, we can confirm that the information is the same we entered in the Plastic SCM checkin (the Plastic checkin is actually mapped to a Git commit).

Conclusion

We have followed the different steps to configure a Jenkins multibranch Pipeline project with Plastic SCM.

We enabled Plastic GitServer to make the Plastic server capable of handling any Git client. This way we can benefit from the Git integration to perform a basic cycle where we create some changesets and Jenkins is able to trigger the builds.

0 comentarios: