大型企业GitLab CI流水线：rules与except/only最佳实践咨询

直接给结论：对于你这个场景，用rules绝对是更优实践，不管是从后续维护、功能扩展还是可读性来说，都比老的only/except靠谱。

为啥rules更好？ #

1. 逻辑直白，不容易踩坑 #

only/except是模糊的匹配逻辑，比如except: tags看起来简单，但如果后续要叠加其他条件（比如只在MR里执行），很容易搞混规则组合逻辑。而你改写的rules写法，第一行明确声明“如果是标签提交，就跳过”，第二行兜底“其他情况都执行”，任何人看了都能立刻明白逻辑，新人接手也不用猜规则。

2. 适配GitLab新特性，避免后续重构 #

GitLab的新功能（比如动态依赖、手动触发、延迟执行等）都是围绕rules设计的，only/except属于传统语法，虽然没被废弃，但官方后续不会再针对它开发新能力。现在换成rules，未来要加新逻辑直接扩展即可，不用再返工重构。

3. 大型项目维护更高效 #

你们是大型企业，流水线作业数量肯定不少。你可以把“排除标签提交”的规则抽成通用模板：

.rules:not-tags:
  rules:
    - if: $CI_COMMIT_TAG
      when: never
    - when: always

然后所有需要排除标签的作业直接继承这个模板就行，以后要修改规则（比如除了标签还要排除特定分支），只改这一个模板就搞定，比每个作业重复写except: tags效率高太多。

4. 支持更精细的执行控制 #

rules支持when: manual（手动触发）、when: delayed（延迟执行）等动作，而only/except只能控制作业是否被包含，无法实现这类精细化控制。就算当前用不上，提前用rules也为未来需求扩展预留了空间。

迁移注意事项 #

• 不要混合使用rules和only/except，两者同时存在时rules会覆盖后者，容易产生逻辑混乱，要换就彻底替换。
• 先在测试分支验证新配置，确保标签提交时目标作业确实被跳过，其他场景正常执行，没问题再推到生产流水线。

内容的提问来源于stack exchange，提问作者Ash Singh