Astropy项目中的GitHub Actions并发控制问题分析与解决方案

在Astropy项目的持续集成流程中，开发团队遇到了一个关于GitHub Actions自动取消机制的有趣问题。这个问题涉及到当多个标签被应用到同一个Pull Request时，如何确保不同的可选作业能够正确执行而不被意外取消。

问题背景

在Astropy的CI/CD流程中，维护人员经常需要通过添加特定标签来触发不同类型的可选作业。例如：

• "Extra CI"标签用于触发定时任务
• "Build all wheels"标签用于触发wheel构建任务

原本的设计预期是这些标签可以独立触发各自的作业流程。然而在实际操作中发现，当维护人员连续添加多个标签时，后触发的作业会导致先前触发的作业被自动取消。这种行为虽然不会阻碍PR合并，但会导致某些预期的测试任务无法完成。

技术分析

这个问题源于GitHub Actions的并发控制机制。在之前的修改中，团队为了确保只有相关标签事件才能触发对应作业，对条件判断进行了严格限制。这种限制虽然解决了无关标签触发错误作业的问题，但同时也影响了自动取消机制的预期行为。

GitHub Actions提供了两种主要的并发控制方式：

1. 工作流级别的并发控制
2. 作业级别的并发控制

团队尝试了两种解决方案：

方案一：工作流级并发控制增强

通过在工作流定义中增加更精确的取消条件判断，尝试区分不同标签触发的作业。然而测试发现，当PR带有多个标签时，部分作业会被跳过，而其他作业则会错误地取消自身。

方案二：作业级并发控制

将并发控制下放到各个作业级别，理论上可以更精确地控制每个作业的取消行为。但实际测试中，所有作业都被跳过，这表明条件判断可能过于严格。

解决方案评估

经过深入分析，团队确认最初引发这个问题的主要因素已经通过其他方式解决（将关键测试任务移动到不监听标签事件的工作流中）。因此，可以考虑以下两种方案：

1. 维持现状：要求维护人员每次只添加一个标签，等待作业完成后再添加下一个标签
2. 回滚部分修改：放松条件判断的限制，虽然可能重新引入少量无关触发，但可以保证多标签场景下的作业执行

最终，考虑到用户体验和实际需求，团队倾向于选择方案二。这种折中方案既能保证主要功能的正常工作，又能提供更流畅的维护体验。

经验总结

这个案例为开发者提供了几个重要启示：

1. GitHub Actions的并发控制机制需要谨慎设计，特别是在多条件触发场景下
2. 条件判断的严格性需要平衡功能正确性和用户体验
3. 系统架构调整（如关键任务迁移）可以解决一些看似复杂的问题
4. 在CI/CD流程中，自动化程度和可控性需要找到合适的平衡点

对于类似项目，建议在进行并发控制设计时：

• 充分测试多标签/多条件场景
• 考虑作业之间的依赖关系
• 评估不同级别（工作流/作业）并发控制的适用性
• 建立清晰的文档说明特殊场景下的操作流程