Building Pipelines with Jenkins using Jenkinsfiles is available mainly since early 2016. Around that time I started working on a blog post about continuous delivery at Zalando Tech tech.zalando.com/blog/ci-pipelines-with-lizzy/ including one task remaining open.
No time ? – there is a in short section at the end.
The pipeline approach described in the post earlier this year is based on Build Pipeline Plugin. It was planned to adapt to Jenkinsfiles with Jenkins 2.0 once available. That happened in the meantime and many other projects now use Jenkinsfiles. This post is about details how to migrate from a Build Pipeline Plugin pipeline to a Jenkinsfiles pipeline using the ghe-backup github repo.
A Build pipeline plugin based pipeline is actually a chained set of Jenkins jobs configured with the Build pipeline plugin settings page. In contrast Jenkinsfiles are groovy scripts and describe a pipeline as a declarative text format.
You can store a Jenkinsfile in an open-source repository like github.com/zalando/ghe-backup/blob/master/Jenkinsfile and do manage your source code versions with everything git(hub) offers. You can’t do this with pipelines defined using Build pipeline plugin though. There are other Jenkins plugins such as the Job dsl plugin that allows also to store jenkins job config as source code in a vcs.
Now, when using Jenkinsfiles of existing projects you have basically two options:
- write a Jenkinsfile from batch
- reuse parts of existing jobs or complete jobs.
Pls note, you can wait for the external job to finish using the wait: true parameter. You can only verify how long a triggered (deployment) job run takes if you tell jenkins to wait for its completion like in wait: true.
Downstream jobs references had to be removed from the existing jobs, because orchestration of jobs is done in the jenkinsfile groovy code.
Not every job run shall end up in a deployment. This is because the job referencing the jenkinsfile is a Mutlibranch Pipeline job. That kind of job scans regularly the github repository and creates jobs for every branch. Jobs created for branches like jenkinsfile should not end up in a deployment.
What if a new branch gets created and recognized by Jenkins and a regarding job is started? The input method call may wait until forever to proceed or cancel the deployment.
To prevent that, the input method call is wrapped into timeout block. That makes sure the job gets canceled if no one is logged into jenkins.
Another interesting approach I do not use in the example above is a Github Organization job. That job kind scans you github organization and creates jobs for every repo that contains a jenkins file.
- Jenkinsfiles is probably the best option to create Pipelines in Jenkins
- existing jobs can be reused in Jenkinsfiles using build job
- Wrap an input method into a timeout block
- multibranch and github organization jobs may save you time creating jobs for branches / repos in your github organization