Maven Release Plugin используется в Jenkins Pipeline

Question

Я использую Jenkins Pipeline для автоматической сборки и развертывания приложений Java. Я также использую maven-release-плагин для развертывания Maven в Artifactory.

Проблема моя Jenkinsfile (или Дженкинс конфигурации трубопровода):

1. Мы совершаем версию 0.1.00-ПАНОРАМА по выпуску филиала
2. Дженкинс трубопровода получить код и выполнить Maven релиз
3. Maven Release изменяет версию на 0.1.00
4. Maven Отметить теги GIT, выполнить и развернуть артефакт
5. Maven Release изменяет версию на 0.2.00-SNAPSHOT и совершает
6. Дженкинс Pipeline обнаружить изменение в GIT, так запускает новую сборку

Вы поняли, что последний шаг создает бесконечный цикл, даже если нет полезного не совершат.

Вот интересная часть моего Jenkinsfile:

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

Как я могу разорвать петлю (во избежание Дженкинс, чтобы вызвать новую сборку, когда Maven совершающее на GIT)?

Благодаря

Answer 1

Благодаря @Daniel Omoto comment, я обнаружил, что Дженкинс предоставляет возможность для GIT опроса. Одним из них является то, что нужно (и при условии, пример для Maven-релиз-плагин!):

Answer 2

Решение может быть изменить после приема крюком, который звонит на уведомление URL Дженкинса:

#!/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

в случае, если кто-то имеет такую ​​же проблему с петлей или что после сборки получить срабатывает, НО есть триггер, который запускает конвейер Дженкинс на каждом толчке в хранилище (вместо опроса).

Вот кто я это сделал: я проверил, содержит ли последнее коммит «[maven-release-plugin]» в комментарии.

Код в 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

ИМХО с появлением мерзавца и тянуть запросы, я не думаю, что с помощью Maven-релиз-плагин или Maven-версия-плагин с конвейера Дженкинс является хорошей идеей ,

Использования многоотраслевых трубопроводов с техникой управления версиями упомянутой здесь в соответствии с непрерывной доставкой: https://axelfontaine.com/blog/dead-burried.html

Используя методику управления версий выше, П.XML теперь выглядит следующим образом:

<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> 

Теперь вы можете производить релизы на сервере Дженкинс очень легко путем настройки трубопровода многоотраслевой с Jenkinsfile построить на все ветки и развернуть только из главного отделения:

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}' 
     } 
    } 
    } 
} 

См. https://jenkins.io/blog/2017/02/07/declarative-maven-project/#set-up о том, как настроить многоканальный трубопровод.

С помощью этой техники вы разрабатываете только не-главные ветви. Затем создайте запрос на перенос, чтобы объединить ваши изменения обратно в мастер-ветку. Затем он должен автоматически разместить ваш артефакт в вашем хранилище артефактов.

---

Добавление

При публикации в репозиторий Maven с использованием описанного выше способа, то pom.xml не будет иметь правильную версию. Чтобы Maven опубликовал правильную версию, используйте плагин flatten-maven: http://www.mojohaus.org/flatten-maven-plugin/usage.html. См. https://maven.apache.org/maven-ci-friendly.html для получения дополнительной информации.