We chose the declarative [1] approach because this one suited our scenario better. We
had to deploy Jenkinsfile
in +10 repositories and there was alot of duplicate code, not to mention
that when our DevOps where fixing some of the Jenkinsfile
, they had to update all the repos.
Therefore, we started from ChrisCooney/jenkins-global-library-simple
[4]
pushed alot of failing builds to understand how everything works, and when we eventually reached our first
working build, we started refactoring everything and splitting the repeating bits into separate reusable
components.
@Library('name-of-library-configured-in-jenkins-admin') _
evenOrOdd(currentBuild.getNumber())
Important
|
declarative [1] pipeline scripts (written in Groovy) must be placed
in the project’s ./vars/ directory in order to be picked up by Jenkins
|
|-src
|---com
|-----gfk
|-------jenkins
|---------components/ <-- classes (mainly what you put in Jenkinsfile script {} blocks)
|-vars/ <-- declarative pipelines (*.groovy scripts)
Basically, there’s a unified repository that contains our shared-library stuff and all other repositories just import this library and call the pipeline function name (in our case it’s the file name - CamelCased).