Multiple projects sharing a jenkinsfile

Question

I have multiple projects with similar build steps and I am looking into reusing a Jenkinsfile pipeline across these projects. I am having a hard time to find documentation on how to implement such an standard (to my opinion) setup.

Here are my requirements :

1) a Jenkinsfile is stored in repo, shared across multiple projects

2) Each project has its own parameter : the project location in the repo.

3) Each project should be independent in Jenkins from a user perspective at least, meaning for example the executions and logs are available in each project's entry in Jenkins

How can I achieve this? based on How do pipeline parameters and jenkins GUI parameters work together? I understand that I can use freestyle jobs however the logs are not available directly with this option. I was suggested also to use Jenkinsfile in each of these independent jobs but to my opinion that sounds like too much unnecessary configuration.

I initially thought about replicating my pipeline job (meaning copy the job including parameters definition, Repository and credential & jenkinfile location definition), the problem I am having with this idea is that every single time I run the job, the pipeline is erasing the parameters default values

e.g. defining a projectSvnPath property in the Jenkinsfile with NO default value will erase my job parameter projectSvnPath value in Jenkins. For that reason I was not able to use this option.

properties([
  parameters([
    string(name: 'projectSvnPath',      description: '*', )
   ])
])

Answer 1

Jenkins has the shared libraries concept to allow multiple builds to share common pipeline instructions without replicating code. details at https://jenkins.io/doc/book/pipeline/shared-libraries/.

At this point what remains unclear is how to allow parameters overrides to persist each time the Jenkinsfile is reloaded. Seems like a weird design choice.

Update 07/13/17 All my parameters are defined in my pipelines to avoid the issue with parameters. I prefer to have parameters defined in my code repository but I can foresee cases where this won't be practical.

Update 04/18 I gave up using shared libraries - the reason for it is that it cannot be tested. It won't run on dev environments (say your PC), so any development needs to be pushed to your repo basically to perform any testing. This is not a sustainable approach for any kind of software development. At the moment my jenkinsfiles are duplicated because I found no workaround for this using jenkins.

Answer 2

I am working on the same pb : Sharing a pipeline across many projects

I am using jenkinsFile.properties (each project has its own) where I put my specific data :

apiName=test
host.Dev=localhost

Then I access my data in the jenkinsFile with

props = readProperties  file: 'jenkinsFile.properties'
targetHost = props["host.${devHost}"]
apiName = props["apiName"]

Then I can use them and work in a very crude way :

    sh '''
        git clone ...
        mvn -X clean install
    '''

Answer 3

I had the same answer to a different thread but the question was another one. It's up to moderators to decide if its a duplicate question and if not this answer is valid as it will be found with search more easily.

You can use the Pipeline Shared Groovy Library plugin to have a library that all your projects share in a git repository. In the documentation you can read about it in detail.

If you have a lot of Pipelines that are mostly similar, the global variable mechanism provides a handy tool to build a higher-level DSL that captures the similarity. For example, all Jenkins plugins are built and tested in the same way, so we might write a step named buildPlugin:

// vars/buildPlugin.groovy
def call(body) {
    // evaluate the body block, and collect configuration into the object
    def config = [:]
    body.resolveStrategy = Closure.DELEGATE_FIRST
    body.delegate = config
    body()

    // now build, based on the configuration provided
    node {
        git url: "https://github.com/jenkinsci/${config.name}-plugin.git"
        sh "mvn install"
        mail to: "...", subject: "${config.name} plugin build", body: "..."
    }
}

Assuming the script has either been loaded as a Global Shared Library or as a Folder-level Shared Library the resulting Jenkinsfile will be dramatically simpler:

Jenkinsfile (Scripted Pipeline)

buildPlugin {
    name = 'git'
}

The example shows how a jenkinsfile passes name = git to the library. I currently use a similar setup and am very happy with it.