Question

我使用Jenkins Pipeline自动构建和部署我的Java应用程序。我还使用maven-release-plugin来执行Maven部署到Artifactory。

问题是我的Jenkinsfile（或Jenkins管道配置）：

我们在发布分支上提交了0.1.00-SNAPSHOT版本
Jenkins Pipeline获取代码，并执行maven发布
Maven Release将版本更改为0.1.00
Maven发布标签GIT分支，提交和部署工件
Maven Release将版本更改为0.2.00-SNAPSHOT并提交
Jenkins Pipeline检测到GIT中的更改，因此触发新构建

您了解最后一步创建了一个无限循环，即使没有有用的提交。

这是我的Jenkins文件中有趣的部分：

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

如何打破循环（当Maven在GIT上提交时，避免Jenkins触发新构建）？

由于

Answer 1

随着git和pull请求的出现，我不认为使用带有Jenkins管道的maven-release-plugin或maven-version-plugin是一个好主意。

使用Multibranch Pipeline和这里提到的版本控制技术更符合持续交付： https://axelfontaine.com/blog/dead-burried.html

使用上面的版本控制技术，pom.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>

现在，您可以通过配置带有Jenkins文件的Multibranch管道，在所有分支上构建并仅从主分支部署，轻松地在Jenkins服务器上生成版本：

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

有关如何配置Multibranch Pipeline的信息，请参阅https://jenkins.io/blog/2017/02/07/declarative-maven-project/#set-up。

使用此技术，您只能在非主分支上进行开发。然后创建一个拉取请求，将您的更改合并回主分支。然后，应该将工件自动部署到工件存储库。

附录

使用上述方法发布到Maven存储库时，pom.xml将没有正确的版本。要让Maven发布正确的版本，请使用flatten-maven-plugin：http://www.mojohaus.org/flatten-maven-plugin/usage.html。

另外，请查看：https://maven.apache.org/maven-ci-friendly.html

Answer 2

感谢@Daniel Omoto comment，我发现Jenkins为GIT投票提供了选项。一个正是我需要的（提供的示例是maven-release-plugin！）：

Answer 3

如果有人对循环有同样的问题或后续构建被触发，那么BUT有一个触发器，它会在每次推送到存储库时启动jenkins管道（而不是轮询）。

以下是我做过的人：我检查了最后一次提交是否包含＆＃34; [maven-release-plugin]＆＃34;在评论中。

jenkinsfile中的代码：

String a = "small";
if (a == "small" || a == "big") {
    // a == "big" won't get executed
}

Answer 4

解决方案可以是更改调用jenkins的通知URL的post-receive挂钩：

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

这是我们在管道中的第一阶段：

stage('Check commit message') {
     when { changelog '.*\\[maven-release-plugin\\].*' }
     steps {
       script {
          pom = readMavenPom file: 'pom.xml'
          currentBuild.displayName = pom.version
          currentBuild.result = 'NOT_BUILT'
       }
       error('Skipping release build')
     }
}

您需要安装https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/插件才能阅读maven pom，或者只为已跳过的版本添加固定说明。发布后的版本将呈灰色。

在詹金斯管道中使用Maven Release Plugin

5 个答案: