问题描述
一位用户在使用 Jenkins Pipeline 结合 Github 进行持续集成 (CI) 时，面临了一个策略问题：在运行检查时应选择检出哪种状态。Jenkins 在发现 pull request (PR) 时提供了三种选项：
1. 使用当前目标分支的合并状态与 PR 合并。
2. 使用当前 PR 的状态。
3. 同时使用当前 PR 的状态和 PR 合并后的状态。
用户希望了解其他人的看法。是仅运行分支的 HEAD 状态，这样运行的内容就清晰明了；还是运行合并状态，以增加合并时的信心。目前，用户选择的是仅使用 PR 分支的 HEAD 状态，并启用了 Github 的功能，如果分支过期，就需要将其合并到主分支。
解决方案
请注意以下操作可能受版本差异影响，建议在操作前备份数据。
最佳实践：选择合并状态进行测试
通常情况下，你希望尽可能地接近最终部署的代码状态来进行测试。这意味着你需要对已经与主分支合并的代码进行测试，因此最好选择第一种选项（先合并，然后测试）。如果你不打算以未合并的状态部署代码（即未合并的状态），那么第二种选项就没有意义。
另一种观点是：良好的持续集成实践涉及尽早合并，频繁合并。这自然会导向选择第一种选项。
方案比较：合并状态 vs. 分支 HEAD
合并状态
- 优势：合并状态运行 CI 测试可以确保代码在合并后的环境中进行了完整测试。这会为合并提供更大的信心，减少合并可能引入的问题。
- 劣势：可能会在测试过程中引入未在实际部署中出现的问题，因为测试环境与实际部署环境可能存在差异。
分支 HEAD
- 优势：运行分支 HEAD 的测试可以确保你正在测试的是分支的当前状态，不涉及合并状态的因素。测试结果更直接。
- 劣势：无法保证代码在合并后的环境中进行了完整测试，合并时可能会引入问题。
如何操作
在 Jenkins Pipeline 中，你可以通过以下步骤来选择合并状态进行测试：
1. 打开你的 Jenkins 任务配置。
2. 在任务配置中找到并配置与 PR 相关的步骤，特别是与检出代码相关的步骤。
3. 在检出步骤中，选择“使用当前目标分支的合并状态与 PR 合并”选项。这可能会以类似下面的方式出现：
groovy
checkout([
$class: 'GitSCM',
branches: [[name: '*/' + env.BRANCH_NAME]],
doGenerateSubmoduleConfigurations: false,
extensions: [[$class: 'PreBuildMerge', options: [fastForwardMode: 'NO_FF']]],
submoduleCfg: [],
userRemoteConfigs: [[url: 'YOUR_GITHUB_REPO_URL']]
])
4. 根据你的任务需求，完成配置并保存。
结论
在选择是否使用合并状态或分支 HEAD 运行 CI 测试时，需要权衡考虑项目的需求和最佳实践。如果你希望在合并后进行完整的测试并增加合并的信心，那么选择合并状态进行测试是一个较好的选择。如果你更关注分支的当前状态，希望更直接地测试当前代码，那么选择分支 HEAD 进行测试可能更适合你的情况。
请在进行任何更改之前备份你的配置和代码。最佳实践可能因具体项目和工具的不同而有所变化，建议根据实际情况调整。