如何让 Gitlab CI 管道始终运行某些作业，而其他作业仅在合并请求时运行? [英] How to have a Gitlab CI Pipeline run some jobs always and other jobs only on merge-requests?

问题描述

TL/DR:我的目标是拥有一个 Gitlab (CE-12.4.2) 管道，它只在合并请求和其他作业上执行一些作业(在合并请求和所有正常推送上)..gitlab-ci.yml 如何才能做到这一点?

我的用例:我有一个运行很多工作的大管道(测试、验证、dep、构建、文档......).现在我添加了一个暂存环境(使用 kubernetes)并让管道构建一个新映像并将其部署在暂存环境中.这使我可以立即打开更改后的(网络)应用程序并查看更改的行为和外观，而无需在本地检查它们.现在构建一个映像并将其部署到 staging 对每次推送来说都需要大量资源，因此我只希望在有人创建合并请求供我审查时进行部署.

一个非常简单的例子:

安装:脚本: ...测试:脚本: ...构建图像:脚本: ...仅:[merge_requests]部署阶段:脚本: ...仅:[merge_requests]

对于所有正常的推送，应该执行install和test作业.

对于合并请求，作业 install、test、build-image 和 deploy-staging 应该被执行.

我尝试过的: Gitlab 有这个功能来定义 only: [merge_requests] 在作业上，这导致该作业仅在执行管道时执行对于合并请求.听起来正是我正在寻找的东西，但有一个很大的收获.一旦该属性应用于管道中的一个作业，该管道中没有该属性的所有其他作业将在合并请求中执行时从管道中删除.起初对我来说这似乎是一个错误，但实际上是

请参阅文档和问题.

user2993689 在 对文档的评论类似的例子:

<块引用>

避免重复管道H2>

TL/DR: My goal is to have a Gitlab (CE-12.4.2) pipeline that executes some jobs only on merge-requests and other jobs always (on merge-requests and on all normal pushes). How must the .gitlab-ci.yml look to do this?

My use-case: I have a big pipeline running a lot of jobs (tests, validation, dep's, build, doc's, ...). Now I have added a staging environment (using kubernetes) and have the pipeline build a new image and deploy that in the staging-environment. This allows me to instantly open up the changed (web-)application and see how the changes behave and look without having to check them out locally. Now building an image and deploying it to staging would be much too resource-heavy to do for every push, so I only want deployments to staging when someone creates a merge-request for me to review.

A very simplified example:

install:
  script: ...

test:
  script: ...

build-image:
  script: ...
  only: [merge_requests]

deploy-staging:
  script: ...
  only: [merge_requests]

For all normal pushes, the jobs install and test should be executed.

For merge-requests, the jobs install, test, build-image and deploy-staging should be executed.

What i have tried: Gitlab has this feature to define only: [merge_requests] on a job, this causes that job to only be executed when the pipeline is executed for a merge-request. Sounds like exactly what I am looking for, but there is a big catch. Once that attribute is applied to one job in a pipeline, all other jobs in that pipeline that do not have that attribute will be removed from the pipeline when executed inside merge-requests. That seemed like a bug to me at first, but is actually documented behaviour:

In the above example, the pipeline contains only a test job. Since the build and deploy jobs don’t have the only: [merge_requests] parameter, they will not run in the merge request.

In order to re-introduce all the other jobs to the pipeline for merge-requests, I have to apply only: [merge_requests] to all other jobs. The problem with that approach is that now these regular jobs do not get executed for normal git-pushes anymore. And I have no way to re-introduce these regular jobs to pipelines for normal pushes, because Gitlab has no support for only: [always] or anything like that.

Now I also have noticed that the only syntax is candidate for deprecation and one should prefer the rules syntax instead, so I took a look at that. There are multiple problems with that approach:

• The only way to detect with rules whether the pipeline is executed for a merge-request or not is to evaluate the variables related to merge-requests, like $CI_MERGE_REQUEST_ID. Unfortunately these variables only exist when only: [merge_requests] is used, which would re-introduce the above problems.
• Rules only allow the conditional application of other attributes, so I still would have to use only, except or when attributes to actually remove or add jobs from or to the pipeline. Unfortunately Gitlab does not support anything like only: [never] or when: never, so i have no way to actually remove or add the jobs.

I also tried to have the jobs depend on another using need or dependencies attributes, this seemed to have no effect on whether the job is included to the pipeline or not.

The last thing I desperately tried was including all jobs always and just mark them as when: manual to be triggered manually by pushing a button. This somewhat works, but is very tedious because the deployment to staging is a multi-job process with every job taking quite some time to finish. So I would see a merge-request, push the button for the first job, wait 5 minutes, press the next button, wait 5 minutes again, and only then am able to use the staging. For many small merge-requests, this would take up a lot of my time and would not be a efficient solution. I also cannot just mark the first of these jobs as manual because Gitlab will then just skip that job and execute that later ones out of order (And again, needs and dependencies seem to have no effect on this when dealing with manually triggered jobs).

What i am a bit baffled about is that after searching the net, I have found nobody having the same problem. Either I am the only Gitlab User that wants to execute some jobs only for merge-requests without excluding all other jobs (which seems highly unlikely) or I am missing something obvious (which seems more likely). Am I missing something or does Gitlab really not support this use-case?

解决方案

From the previous answer:

But there is a problem. This example launches two pipelines for every push after MR is created. One for only: [branch], one for only: [merge_requests]

Check if the last GitLab 13.8 (January 2021) can help:

Use both branch and MR pipelines without duplication

Previously it was not possible to run pipelines for branches first, then switch to merge requests pipelines when the MR is created.

Consequently, with some configurations, a push to a branch could result in duplicate pipelines if a merge request was already open on the branch: one pipeline on the branch and another for the merge request.

Now you can use the new $CI_OPEN_MERGE_REQUESTS predefined environment variable in your CI configurations to switch from branch pipelines to MR pipelines at the right time, and prevent redundant pipelines.

See Documentation and Issue.

user2993689 points out in the comments to the documentation for a similar example:

Avoid duplicate pipeline

这篇关于如何让 Gitlab CI 管道始终运行某些作业，而其他作业仅在合并请求时运行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！