Git 2.27 (Q2 2020) 采用了另一种方法:用户可以指定要构建哪些分支,而不是始终通过 Actions 在 GitHub 上构建所有分支。
请参见 Jeff King(peff)于 2020 年 5 月 7 日提交的 e76eec3 提交记录。 (由 Junio C Hamano(gitster)于 2020 年 5 月 13 日在提交记录 dd4a287 中合并。)
ci
:允许GitHub Actions的每个分支进行配置
Signed-off-by: Jeff King
根据个人开发者的工作流程,我们的GitHub Actions CI作业在每个分支上运行可能会很方便,也可能会很烦人。
例如,如果您有许多未完成的工作进展分支,并经常对其进行变基,则会收到许多不感兴趣的失败报告(更不用说浪费CPU了)。
此提交添加了一个新作业,该作业检查存储库中的特殊分支的CI配置,然后运行它在那里找到的shell脚本来决定是否跳过其余的测试。
如果缺少该分支或脚本,则默认将继续为所有引用运行测试。
已经讨论了一些替代方案:
其中一种选择是在提交本身中携带有关是否应进行测试的信息,可以在树本身中(更改工作流程YAML文件)或提交消息中("[skip ci]"标志或类似标志)中实现。但是这些使用起来很令人沮丧且容易出错:
- 您必须手动将它们应用于要标记的每个分支
- 很容易泄漏到其他工作流程中,例如通过电子邮件发送补丁
我们也可以尝试从分支名称中获取一些信息。 但是,这会导致关于默认值应该是“关闭”还是“开启”的争论,并且覆盖仍然变得有些笨拙。
如果我们默认为“开启”,则必须记住适当命名分支以跳过CI。
如果为“关闭”,则必须扭曲分支名称或使用额外的refspec重复推送。
相比之下,此提交的解决方案让您指定配置一次并忘记它,而所有数据都在其自己的ref中,可以由各个分支进行更改,而无需触及主树。
在列表讨论中出现了一些设计决策。 我在此总结一下:
我们可以使用GitHub的API检索配置引用,而不是真正的checkout(然后只通过一些javascript操作它)。
无论哪种方式,我们仍然必须从它的虚拟机上旋转并通过网络与GitHub联系,因此速度不会快多少。
我选择使用shell来保持与其他工具的相似性(实际上可以在任何您想要的语言中实现allow-refs)。 这也使得您可以在本地测试脚本,并在正常的git.git树的上下文中修改它。
我们可以将众所周知的refname保留在refs/heads/
之外,以避免混乱的分支命名空间。 但是这使操作变得笨拙。
相比之下,您只需"git checkout ci-config
"即可进行更改。
我们可以假设ci/config/allow-refs.sample
:
<code>
case "$1" in
refs/heads/for-ci*) true ;;
refs/heads/my-integration-branch) true ;;
*) false ;;
esac
</code>
所有与.github/workflows相关的操作都需要:
即:
git -c protocol.version=2 clone \
--no-tags \
--single-branch \
-b ci-config \
--depth 1 \
--no-checkout \
--filter=blob:none \
https://github.com/${{ github.repository }} config-repo \
&& \
cd config-repo \
&& \
git checkout HEAD -- ci/config
即:
enabled=yes
if test -x config-repo/ci/config/allow-ref &&
! config-repo/ci/config/allow-ref '${{ github.ref }}'
then
enabled=no
fi
[skip ci]
提交信息策略也很有趣:https://dev59.com/m1IH5IYBdhLWcg3weum6#66114678 - VonCREADME.md
文件的CI提交。这就是为什么我认为你的答案在那里很相关。 - Nikolas Charalambidis