如何动态选择要在 Jenkins 构建中使用的 git 分支

我正在尝试为 Jenkins 构建服务器创建一个新的项目配置。为了简化我想要做的事情，我将仅使用两个组件来描述问题。

组分A

• 该组件的更改会触发该项目在 CI 服务器上的构建。
• CI 服务器具有静态配置的分支来监视更改和构建。例如。掌握或开发分支。
• 该组件包含一个配置文件，其中包含它所依赖的 ComponentB 所需版本。

组件B

• 对此组件的更改不会触发 CI 服务器上该项目的构建（将有另一个项目来涵盖 ComponentB 的开发）。
• 组件的各个版本都被标记
• ComponentA 在其配置文件中具有所需的 ComponentB 版本
• CI 服务器不知道要签出哪个分支（标签），直到以某种方式解析了 ComponentA 的配置文件。

在詹金斯上实现这一目标的正确方法是什么？我试图找出如何添加解析配置文件并使 Git 插件根据 ComponentB 的预期版本检查分支的动态行为，但到目前为止我还没有任何线索。

在下一步中，我什至可能希望在配置文件中包含通配符（如 5.3.*），因此我必须找到与通配符匹配的最新 ComponentB 标签。

EDIT

现在我发现我过于简化了我的问题，并且由于简化，主要限制不再存在。

主要限制是组件 A 和 B 必须一起构建。不可能单独构建它们，因为它们形成一个可执行文件/库，并且构建脚本需要来自两个组件的源文件。

如果你问为什么会有这么奇怪的配置，我们先给组件 A 和组件 B 做一些描述：

• ComponentA：本机平台特定代码
• ComponentB：本机平台独立代码

可能有许多组件 A - 每个平台一个，但只有一个组件 B。将特定的 A 与 B 合并会生成单个平台的完整源代码，但并非每个平台都可以更新到 B 的最新版本，因此它需要控制应该使用哪个版本的 B 来构建。

实现您想要的效果的一种选择是使用以下设置：

创建两个 Jenkins 作业：

• “组件 A”（SCM 更改时自动触发）
• “组件B”（“手动”触发）

Step #1

定义branch 构建参数 https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build对于“组件 B”：

使用此参数作为“Git Plugin”分支说明符：

现在您应该能够通过为其指定适当的分支（标签）参数来手动触发“组件 B”构建，例如tags/5.3.0.

Step #2

将新的“执行外壳”构建步骤添加到“组件 A”构建中，这将从工作区的配置文件中提取“组件 B”版本，并准备b.properties具有“组件 B”构建参数的文件。

安装一个参数化触发器 https://plugins.jenkins.io/parameterized-triggerJenkins 插件，并向“组件 A”作业添加新的“触发/调用在其他项目上构建”构建步骤：

使用您的b.properties文件作为构建参数的来源。

现在，每次重新构建“组件 A”时，都会触发新的“组件 B”构建，并以目标分支/标签作为构建参数。

添加通配符支持

如果你想支持通配符版本，你可以使用git ls-remote命令查找最新标签，如下所示：

#B=$(obtain B version from the config file in a usual way)   

LATEST=$(\
    git ls-remote --tags YOUR_REPOSITORY_URL "$B"\
    |cut -d / -f3|sort -r --version-sort|head -1\
)
 
cat <<EOF > b.properties
    branch=tags/$LATEST
EOF

这将列出远程“组件 B”存储库中与“B”版本模式匹配的所有标签，并将最新版本号保存在LATEST多变的。

将其添加到“组件 A”作业的“执行 Shell”步骤中， 它应该能够处理版本号模式，例如：5.3.*

问题是 shell 脚本将以 Jenkins 守护程序用户身份运行， 因此它必须配置正确的凭据才能访问远程 Git 存储库（例如通过 ssh 公钥）。

或者，您可能想查看凭证绑定插件 https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Binding+Plugin，以重用存储在 Jenkins 本身中的 Git 凭据。

使用 Jenkins 2.0 风格的管道

您还可以使用 Jenkins 2.0 风格来解决手头的任务Pipeline https://jenkins.io/doc/book/pipeline/，这将允许您将组件 A 和 B 的代码检出到单个工作区中，然后对它们应用一些常见的构建步骤。

你的管道可能看起来像这样：

node {

   //Settings
   def credentialsId = '8fd28e34-b04e-4bc5-874a-87f4c0e05a03'    
   def repositoryA = 'ssh://[email protected] /cdn-cgi/l/email-protection/projects/a.git'
   def repositoryB = 'ssh://[email protected] /cdn-cgi/l/email-protection/projects/b.git'

   stage('Checkout component A') {
      git credentialsId: credentialsId , 
      url: repositoryA , branch : "master"
   }
   
   stage("Resolve and checkout component B") {
      def deps = readProperties file: 'meta.properties'
      echo "Resolved B version = ${deps['b']}"
      
      dir("module/b") {
           //Clone/Fetch Component B 
           checkout scm:[
                $class: 'GitSCM', 
                userRemoteConfigs: [[url: repositoryB, credentialsId: credentialsId]], 
                branches: [[name: 'refs/tags/*']]
           ], 
           changelog: false, poll: false

           //Checkout the tag, matching deps['b'] pattern     
           sshagent([credentialsId]) {
                sh "git checkout \$(git tag -l \"${deps['b']}\" |sort -r --version-sort|head -1)"
           }
      }
   }
   
   stage("Build A+B") {
        //Apply a common build step
   }

}

这里我们使用“readProperties”命令，它是管道实用程序步骤插件 https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Utility+Steps+Plugin从中提取“组件 B”版本模式meta.properties。还有 readYaml、readJSON 命令可用。

接下来我们获取/克隆“组件 B”，其中changelog: false, poll: false标志，以防止其注册用于 SCM 轮询，并将其放入当前工作区的“module/b”文件夹中。

然后调用 shell 命令来根据我们上面获得的版本模式选择标签，并签出它（5.3.* 样式通配符也应该有效）。

The sh调用，被包装在sshagent https://wiki.jenkins-ci.org/display/JENKINS/SSH+Agent+Plugin，使其重用适当的 来自 Jenkins 凭证存储的凭证。