长时间运行的作业不应阻止MR被合并。

Question

考虑一个具有以下作业的管道：

• build：运行构建并花费1分钟
• report：运行静态代码分析，将结果发布到MR，耗时59分钟

应该尽快通知开发人员report阶段的结果，但不应该阻止MR被合并。管道的行为应该是这样的：

1. 在MR可以合并之前，build必须总是成功的。
2. report始终应该最终启动并成功执行，但不应该强制等待它才能合并MR. .

在gitlab中是否有可能创建这样的管道？

到目前为止，我知道以下几种选择：

1. 禁用"https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds“设置:在这种情况下，可以合并MR，即使build没有成功。
2. 将allow_failure设置为report为true。在这种情况下，可以在build完成后通过取消report作业来合并MR，但这违反了应该始终执行报表的要求。此外，如果您必须取消一个可选的工作，然后才能进行合并，则开发人员的经验很差。
3. 合并后执行report作业。这有两个缺点：
   • 只有当MR被合并时，我才会得到报告，而不是尽快。
   • report工作不能将其结果发布到MR，后者将通知相关人员。

Answer 1

您可以将report作业移动到子管道(=项目中的一个单独的.yml文件)，并使用关键字和触发它，而不需要 strategy: depend。这使您可以在不等待作业的情况下触发作业，并且无需考虑其在管道中的状态。