rules 决定的是生成，不是执行

一句话总结

rules不是在抓捕开始时询问“要不要抓”的装置，而是在管道制作的瞬间决定“要不要把这个抓捕列入清单”的装置。

为什么需要这个？

一个管道必须应对多种情况，这是问题的出发点。在功能分支中，他们只想运行测试，在合并请求中，他们想在测试中添加安全扫描，在基本分支中，他们甚至要进行分阶段部署，一旦标记，他们就会准备运营部署，但他们希望有人按下按钮。将这四个问题分成四个文件，则共同部分会分成四个部分，很快就会变得不同。

以前的语法only/except勉强接受了这个要求。虽然可以列出条件，但不能为每个条件附加不同的动作（自动执行、手动批准、允许失败），也不能同时使用两个键。rules是将条件和动作绑定到一个项目上，克服这一限制的语法，现在在新设置中only/except没有理由使用。将两者混合使用时，GitLab会拒绝设置。

怎么行动

rules是项目中的列表，从上面开始读，只应用第一个触及条件的项目后停止。这就是所谓的“只匹配第一个”的特性。所以没有条件的项目总是触及，无论下面写什么，都永远不会被读取。没有条件的when: never将放在列表中的话，后面规则就会全部消失，因为这个错误不会出现任何错误，所以很难找到无法发布的原因。

项目可以具备的三种条件。if是变量表达式$CI_COMMIT_BRANCH == "main"像这样写。changes看看这次变更是否包含特定路径。exists查看存储库是否存在特定文件。

被抓时的动作是when决定这个。on_success如果前途全部成功的话，会自动，manual制作银色夹子，但必须有人按下才能开始，always即使前路失败，never根本不做夹子。manual和一起使用的allow_failure的意义容易混淆，这false无论是执政党还是反对党，这种手动抓捕都将成为真正的批准门槛。true即使不按面，管道也会以成功告终。

在这里再次确认的是评价时间点。rules在制作管道时被评估一次，在开始捕获时不会再看。所以不能用前捕获执行中创建的值来决定后捕获的执行是否。这样的条件分支是rules不是去，而是抓中的script必须在处理。

在现场相遇的样子

最常见的症状是提交一个时出现两个管道。分支管道和合并请求管道都受到相同条件的限制，跑者资源翻倍，状态显示也变成两个。解决的方法不是在每个任务中添加条件。workflow:rules阻止只制作一条管道本身。

第二常见的是运营部署工作。when: manual走着走着就停了下来allow_failure把放在基本值上。我以为是批准闸道，但有一天会看到一个没有人按下的管道以绿色结尾的场景。

接下来要看的

在忙碌之间递文件的artifacts，并且在执行和执行之间节省时间cache看到。名字相似，经常混淆，但是一样东西。