Używanie wtyczki Maven Release w Jenkins Pipeline

Question

Używam Jenkins Pipeline do automatycznego budowania i wdrażania moich aplikacji Java. Używam także wtyczki maven-release do wykonania Mavena do Artifactory.

Problem jest mój Jenkinsfile (lub Jenkins Pipeline Configuration):

1. Zobowiązujemy wersji 0.1.00-SNAPSHOT na uwalnianiu oddziału
2. Jenkins Pipeline uzyskać kod i wykonaj maven uwolnienia
3. Maven Release zmienia wersję na 0.1.00
4. Tagi wydania Maven Oddział GIT, zatwierdzenie i wdrożenie artefaktu
5. Maven Release zmienia wersję na 0.2.00-SNAPSHOT i zatwierdza
6. Jenkins Pipeline wykryć zmiany w GIT, więc uruchamia nową kompilację

zrozumiałeś, że ostatni krok tworzy nieskończoną pętlę, nawet jeśli nie jest przydatna popełnić.

Oto interesująca część mojego Jenkinsfile:

sshagent([git_credential]) { 
    sh "${maven_bin} --settings ${maven_settings} -DreleaseVersion=${release_version} -DdevelopmentVersion=${development_version} release:prepare release:perform -B" 
} 

Jak mogę przerwać pętlę (unikać Jenkins wywołać nową kompilację gdy Maven popełnia na GIT)?

Dzięki

Answer 1

Dzięki @Daniel Omoto comment, okazało się, że Jenkins zapewnia opcję GIT odpytywania. Jednym z nich jest dokładnie to, co potrzebne (i pod warunkiem przykładem jest dla maven-RELEASE-plugin!):

Answer 2

roztworu można zmienić post-otrzymywać hak, który jest wywołanie URL notyfikacji Jenkins:

#!/bin/bash 
git_log=$(git log --branches -1) 
if ! [[ $git_log =~ .*maven-release-plugin.* ]] ; 
then 
curl http://buildserver:8080/git/notifyCommit?url=ssh://git@server:22/projects/Name.git; 
fi 

Answer 3

W przypadku gdy ktoś ma ten sam problem z pętli albo że kolejny buduje się wyzwolony, ale ma wyzwalacz, który zaczyna rurociągu Jenkins na każdym naciśnięciem do repozytorium (zamiast odpytywania).

Oto, co zrobiłem: Sprawdziłem, czy ostatnie zatwierdzenie zawiera "[maven-release-plugin]" w komentarzu.

kod w jenkinsfile:

def lastCommit = sh returnStdout: true, script: 'git log -1 --pretty=%B' 

if (lastCommit.contains("[maven-release-plugin]")){ 
      sh "echo Maven release detected" //dont trigger build 

     } else { 
      sh "echo Last commit is not from maven release plugin" //do build steps 
      <..build Job...> 
     } 

Answer 4

IMHO z nadejściem git i wyciągnąć wnioski, nie sądzę użyciu Maven-release-plugin lub Maven-version-plugin z rurociągu Jenkins jest dobrym pomysłem .

Stosując wielobranżowy rurociągu techniki wersjami wymienionego tutaj jest bardziej zgodny z ciągłego podawania: https://axelfontaine.com/blog/dead-burried.html

Stosując technikę wersjami powyżej pom.xml teraz wygląda tak:

<project> 
    ... 
    <version>${revision}</version> 

    <properties> 
     <!-- Sane default when no revision property is passed in from the commandline --> 
     <revision>0-SNAPSHOT</revision> 
    </properties> 

    <scm> 
     <connection>scm:git:your-git-repo-url</connection> 
    </scm> 

    <distributionManagement> 
     <repository> 
      <id>artifact-repository</id> 
      <url>your-artifact-repo-url</url> 
     </repository> 
    </distributionManagement> 

    <build> 
     <plugins> 
      <plugin> 
       <artifactId>maven-scm-plugin</artifactId> 
       <version>1.9.5</version> 
       <configuration> 
        <tag>${project.artifactId}-${project.version}</tag> 
       </configuration> 
      </plugin> 
     </plugins> 
    </build> 
    ... 
</project> 

Teraz można produkować wersje na serwerze Jenkins bardzo łatwo przez skonfigurowanie wielobranżowy Pipeline z Jenkinsfile budować na wszystkich oddziałach i wdrożyć tylko z głównego oddziału:

pipeline { 
    agent any 
    environment { 
    REVISION = "0.0.${env.BUILD_ID}" 
    } 
    triggers { 
    pollSCM('') 
    } 
    options { 
    disableConcurrentBuilds() 
    buildDiscarder(logRotator(numToKeepStr: '30')) 
    } 
    tools { 
    maven '3.5.2' 
    jdk 'jdk8' 
    } 
    stages { 
    stage ('Initialize') { 
     steps { 
     sh ''' 
      echo "PATH = ${PATH}" 
      echo "M2_HOME = ${M2_HOME}" 
     ''' 
     } 
    } 
    stage ('Build') { 
     steps { 
     sh 'mvn clean package' 
     } 
    } 
    stage ('Deploy') { 
     when { 
     branch 'master' 
     } 
     steps { 
     script { 
      currentBuild.displayName = "${REVISION}" 
     } 
     sh 'mvn deploy scm:tag -Drevision=${REVISION}' 
     } 
    } 
    } 
} 

Zobacz https://jenkins.io/blog/2017/02/07/declarative-maven-project/#set-up, jak skonfigurować potok Multibranch.

Dzięki tej technice rozwijasz się tylko na gałęziach nieprzezwyciężonych. Następnie utwórz żądanie ściągnięcia, aby scalić zmiany z powrotem do gałęzi głównej. To powinno następnie wdrożyć twój artefakt automatycznie do repozytorium artefaktów.

---

Uzupełnienie

Podczas publikowania do repozytorium Maven stosując powyższą metodę, pom.xml nie będzie miał odpowiedniej wersji. Aby zmusić Mavena do opublikowania odpowiedniej wersji, użyj wtyczki spłaszczonej-maven: http://www.mojohaus.org/flatten-maven-plugin/usage.html. Aby uzyskać więcej informacji, patrz https://maven.apache.org/maven-ci-friendly.html.