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

组件A

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

组件B

• 对此组件的更改不会触发在 CI 服务器上构建此项目(将有另一个项目来涵盖 ComponentB 的开发)。
• 标记各个版本的组件
• ComponentA 在其配置文件中有所需的 ComponentB 版本
• 在 ComponentA 的配置文件被解析之前，CI 服务器不知道要检查哪个分支(标签)。

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

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

编辑

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

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

如果你问为什么这么奇怪的配置，让我们给组件 A 和 B 一些描述:

• ComponentA: native 平台特定代码
• ComponentB:与 native 平台无关的代码

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

最佳答案

实现您想要的一个选项是使用以下设置:

创建两个 Jenkins 作业:

• “组件 A”(在 SCM 更改时自动触发)
• “组件 B”(“手动”触发)

步骤 #1

定义分支 build parameter对于“组件 B”:

将此参数用作“Git Plugin”分支说明符:

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

步骤 #2

在您的“组件 A”构建中添加一个新的“执行 Shell”构建步骤，这将从工作区中的配置文件中提取“组件 B”版本，并准备 b.properties 文件使用“组件 B”构建参数。

安装 Parameterized Trigger Jenkins 插件，并在“组件 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”作业的“执行外壳”步骤中， 它应该能够处理版本号模式，例如:5.3.*

需要注意的是，shell 脚本将以 Jenkins 守护程序用户身份运行， 所以它必须配置正确的凭据，才能访问远程 Git 存储库(例如，通过 ssh pubkey)。

您也可以查看 Credentials Binding Plugin ，以重用存储在 Jenkins 本身中的 Git 凭据。

使用 Jenkins 2.0 风格的管道

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

您的管道可能如下所示:

node {

   //Settings
   def credentialsId = '8fd28e34-b04e-4bc5-874a-87f4c0e05a03'    
   def repositoryA = 'ssh://git@stash.com/projects/a.git'
   def repositoryB = 'ssh://git@stash.com/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”命令，它是Pipeline Utility Steps Plugin 的一部分。从 meta.properties 中提取“组件 B”版本模式。还有 readYaml、readJSON 命令可用。

接下来我们使用 changelog: false, poll: false 标志获取/克隆“组件 B”，以防止它被注册为 SCM 轮询，进入“模块/b”当前工作区的文件夹。

然后调用shell命令选择标签，根据我们上面获得的版本模式，并检查它(5.3.*风格的通配符也应该工作)。

sh 调用包含在 sshagent 中，使其重用适当的 来自 Jenkins 凭据存储的凭据。

https://stackoverflow.com/questions/43183495/