CODEWITHSUNDEEP
mavenjenkinsjenkins-pipeline
Shiva
Shiva

Reputation: 727

Which is better, One Jenkinsfile for similar pipelines or exclusive Jenkinsfile

We have a bunch of maven projects to be built and deployed to Nexus, we are upgrading from Jenkins 1.500 to latest version this opens pipeline possibilities for us. After good amount of research we wrote a single pipeline script that would query our bitbucket instance to find project key and repo so this script can be reused.

Stages involved: Checkout, Build, Test & Nexus Deploy

Checkout stage involves different git repo, after that steps are the same

Now we have this design, so similar projects uses same Jenkinsfile, is this correct?

As per current design Jenkinsfile under maven_nexus repo of Pipeline project (bitbucket structure) will be used for at least 400 projects. We find this as advantage since,

Is there any disadvantage? are we doing something wrong by querying bitbucket instance from Jenkins pipeline script for every build? (though time/network cost is low, I'm not sure if this is the way to go).

So far in forums, I have read that project teams maintain their own Jenkinsfile. Is there good reason to give teams permission to edit at their will.

Upvotes: 2

Views: 1454

Answers (1)

Spencer Malone
Spencer Malone

Reputation: 1509

There's no inherent "disadvantage" outside of a lack of customizable behavior. My instinct is to tell you to look into writing a Shared Library (described here: https://jenkins.io/doc/book/pipeline/shared-libraries/). This will let you store your "Checkout, Build, Test & Nexus Deploy" stages in one script that they can call, but they could also add their own work if they wanted something like linting, static analysis, or other custom behavior that you don't normally include. Specifically, look at the section called "Defining a more structured DSL". They give the following example (once you've setup your shared library):

Shared Library Step Definition:

// 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: "..."
    }
}

Corresponding Jenkinsfile:

buildPlugin {
    name = 'git'
}

So, if your teams were using this pattern, they could add to that by doing something like...

node() {
    stage('Lint') {
        sh 'exit 0'
    }
}

buildPlugin {
    name = 'git'
}

Upvotes: 4

Related Questions