9

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

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

一个非常简单的例子：

install:
  script: ...

test:
  script: ...

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

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

对于所有正常推送，install应test执行作业。

对于合并请求，应执行作业install、、和。testbuild-imagedeploy-staging

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

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.

为了将所有其他工作重新引入合并请求的管道，我必须申请only: [merge_requests]所有其他工作。这种方法的问题在于，现在这些常规作业不再为正常的 git-push 执行。而且我无法将这些常规作业重新引入管道以进行正常推送，因为 Gitlab 不支持only: [always]或类似的东西。

现在我也注意到only语法是弃用的候选者，应该更喜欢rules语法，所以我看了一下。这种方法存在多个问题：

  • rules检测管道是否针对合并请求执行的唯一方法是评估与合并请求相关的变量，例如$CI_MERGE_REQUEST_ID. 不幸的是，这些变量仅在使用时才存在only: [merge_requests]，这将重新引入上述问题。
  • 规则只允许有条件地应用其他属性，所以我仍然必须使用only,except或when属性来实际从管道中删除或添加作业。不幸的是，Gitlab 不支持only: [never]or之类的东西when: never，所以我无法实际删除或添加作业。

我还尝试让作业依赖于另一个使用need或dependencies属性，这似乎对作业是否包含在管道中没有影响。

我拼命尝试的最后一件事是始终包括所有作业，只需将它们标记为when: manual通过按下按钮手动触发即可。这有点工作，但非常乏味，因为部署到登台是一个多作业过程，每项作业都需要相当长的时间才能完成。所以我会看到一个合并请求，按下第一个作业的按钮，等待 5 分钟，按下下一个按钮，再次等待 5 分钟，然后才能使用暂存。对于许多小的合并请求，这会占用我很多时间并且不是一个有效的解决方案。我也不能只将这些作业中的第一个标记为手动，因为 Gitlab 将跳过该作业并无序执行后面的作业（同样，在处理手动触发的作业needs时dependencies似乎对此没有影响）。

我有点困惑的是，在网上搜索后，我发现没有人有同样的问题。要么我是唯一一个只想为合并请求执行某些作业而不排除所有其他作业（这似乎极不可能）的 Gitlab 用户，要么我错过了一些明显的东西（这似乎更有可能）。我错过了什么还是 Gitlab 真的不支持这个用例？

4

3 回答 3

5

从上一个答案：

但有一个问题。此示例在创建 MR 后为每次推送启动两个管道。一为only: [branch]一为only: [merge_requests]

检查最后一个GitLab 13.8（2021 年 1 月）是否可以提供帮助：

同时使用分支和 MR 管道，无需重复

以前不可能先为分支运行管道，然后在创建 MR 时切换到合并请求管道。

因此，对于某些配置，如果分支上已经打开了合并请求，则推送到分支可能会导致重复的管道：分支上的一个管道和合并请求的另一个管道。

现在，您可以$CI_OPEN_MERGE_REQUESTS在 CI 配置中使用新的预定义环境变量在正确的时间从分支管道切换到 MR 管道，并防止冗余管道。

https://about.gitlab.com/images/13_8/yaml_example_avoid_duplicate_pipelines.png -- 使用分支和 MR 管道而不重复

请参阅文档和问题。

user2993689在文档的评论中指出了一个类似的例子：

避免重复管道

于 2021-01-23T21:25:40.827 回答
1

可以将一些作业添加到 MR 管道。我从这里得到了例子： https ://docs.gitlab.com/ee/ci/merge_request_pipelines/index.html# exclude-certain-jobs

总体思路：您only: [branch, merge_requests]为每个作业定义，并为部署作业用only: [merge_requests].

.only-default: &only-default
  only:
    - branches
    - merge_requests

build:
  stage: build
  tags:
    - build
  <<: *only-default
  script:
    - echo build

deploy mr:
  stage: deploy
  tags:
    - build
  only:
    - merge_requests
  script:
    - echo "deploy on MR"

但有一个问题。此示例在创建 MR 后为每次推送启动两个管道。一为only: [branch]，一为only: [merge_requests]。这就是only: [merge_requests]工作方式，它会在每次 MR 更改时启动工作。新的提交绝对是一个改变。

似乎没有解决方案可以仅针对某些事件启动管道 - 例如 MR 创建。

但我认为一些解决方法是可能的：

  1. 每个管道都存在部署暂存作业
  2. 作业脚本检查是否为当前分支创建了 MR
  3. 如果创建了 MR，则为该 MR 设置脚本标签，例如“部署部署”
  4. 如果这个标签已经存在，或者没有创建 MR，什么都不做。

GitLab API、curl 和 jq 可以帮助解决这个问题。如果我有空闲时间，我一定会尝试写它:)。

于 2020-01-18T18:12:19.690 回答
0

我有同样的问题。

如GitLab Docs所述，您必须配置整个管道以在合并请求管道中运行。

这可以通过在 .gitlab-ci.yml 之上添加以下内容来实现。

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

希望我能帮上忙！

于 2022-02-07T12:41:54.777 回答