Wie man eine Jenkins 2 Pipeline so konfiguriert, dass Jenkinsfile eine vordefinierte Variable verwendet

Question

Ich habe mehrere Projekte, die eine Jenkinsfile verwenden, die praktisch identisch ist. Der einzige Unterschied ist das git-Projekt, das es auschecken muss. Dies zwingt mich ein Jenkinsfile pro Projekt zu haben, obwohl sie die gleiche teilen konnten:

node{ 
    def mvnHome = tool 'M3' 
    def artifactId 
    def pomVersion 

    stage('Commit Stage'){ 
     echo 'Downloading from Git...' 
     git branch: 'develop', credentialsId: 'xxx', url: 'https://bitbucket.org/xxx/yyy.git' 
     echo 'Building project and generating Docker image...' 
     sh "${mvnHome}/bin/mvn clean install docker:build -DskipTests" 
    ... 

Gibt es eine Möglichkeit, die git Position als Variable bei der Schaffung von Arbeitsplätzen vorkonfigurieren, so kann ich die gleiche Jenkinsfile wiederverwenden?

... 
    stage('Commit Stage'){ 
     echo 'Downloading from Git...' 
     git branch: 'develop', credentialsId: 'xxx', url: env.GIT_REPO_LOCATION 
    ... 

Ich weiß, dass ich es auf diese Art und Weise einstellen:

Dieses Projekt ist parametriert -> String Parameter -> GIT_REPO_LOCATION, default = http://xxxx, und greifen Sie mit env.GIT_REPO_LOCATION.

Der Nachteil ist, dass der Benutzer aufgefordert wird, den Build mit dem Standardwert zu starten oder zu ändern. Ich würde brauchen, dass es für den Benutzer transparent ist. Gibt es einen Weg, es zu tun?

Answer 1

Sie können Pipeline Shared Groovy Library plugin verwenden, um eine Bibliothek zu haben, die alle Ihre Projekte in einem Git-Repository teilen. In der documentation können Sie darüber im Detail lesen.

Wenn Sie viele Pipelines haben, die sich größtenteils ähneln, bietet der globale Variablenmechanismus ein praktisches Tool zum Aufbau einer höheren DSL-Ebene, die die Ähnlichkeit erfasst. Zum Beispiel werden alle Jenkins Plugins gebaut und auf die gleiche Weise getestet, so dass wir vielleicht einen Schritt namens buildPlugin schreiben:

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

Angenommen, das Skript hat entweder als globalen Shared Library geladen oder als eine Ordnerebene Shared Library die resultierende Jenkinsfile wird sein dramatisch einfacher:

Jenkinsfile (Scripted Pipeline)

buildPlugin { 
    name = 'git' 
} 

Das Beispiel zeigt, wie eine jenkinsfile name = git an die Bibliothek übergibt. Ich benutze derzeit ein ähnliches Setup und bin sehr zufrieden damit.

Answer 2

Statt eine Jenkinsfile in jeder Git-Repository zu haben, können Sie eine zusätzliche git-Repository aus, in dem Sie die gemeinsamen Jenkinsfile bekommen - dies funktioniert, wenn Pipeline Typ Job verwenden und die Option Pipeline-Skript von SCM auswählen. Auf diese Weise checkt Jenkins das Repo aus, in dem Sie die übliche Jenkins-Datei haben, bevor Sie das Benutzer-Repo auschecken.

Wenn der Job automatisch ausgelöst werden kann, können Sie in jedem Git Repo einen Post-Receive-Hook erstellen, der die Jenkins-Pipeline mit dem Repo als Parameter aufruft, damit der Benutzer den Job nicht manuell eingeben muss der Repo als Parameter (GIT_REPO_LOCATION).

Falls der Job nicht automatisch ausgelöst werden kann, ist die am wenigsten lästige Methode, die ich mir vorstellen kann, ein Choice-Parameter mit einer Liste von Repositories anstelle eines String-Parameters.