Gitlab-ci:如果 MR 存在,则触发 merge_request 分离管道,如果不存在,则触发源分支管道。这两条管道不应同时运行

ham*_*r89 6 gitlab sonarqube gitlab-ci

当我创建 MR 时,我想在 MR(合并请求)命令部分查看声纳结果。

我的主要期望:

  • 如果源分支存在现有 MR,则触发分离管道(不触发功能管道。我只需要那个来检查 MR 命令中的声纳结果)
  • 如果源分支没有现有的 MR,则只需触发正常的功能(源)分支管道

我尝试用下面的示例阶段来做到这一点。但是当我将提交推送到源管道时,而源分支存在 MR。我仍然得到双管道。分离管道和源管道正在运行,我不想同时看到两者,而且除了不使用规则配置之外。如何将除部分与规则部分集成。

这是我的 gitlab-ci 阶段:

deploy:
  stage: deployment
  when: manual
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CUSTOM_VARIABLE == "true" || $CUSTOM_VARIABLE == "true"'
  script:
    - ....
    - ....
  except:
    - tags
    - main
Run Code Online (Sandbox Code Playgroud)

我还尝试了以下规则,如果其中一项符合我的条件,则不要运行另一项。但它仍然触发两条管道。

deploy:
  stage: deployment
  when: manual
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CUSTOM_VARIABLE == "true"'
      when: on_success
    - if: '$CI_PIPELINE_SOURCE == "push" && $CUSTOM_VARIABLE == "true"'
      when: on_success
  script:
    - ....
    - ....
  except:
    - tags
    - main
Run Code Online (Sandbox Code Playgroud)

syt*_*ech 14

涵盖在workflow:rules模板中,在这种情况下,您可以使用CI_OPEN_MERGE_REQUESTS变量来确定是运行合并请求的管道还是仅运行功能分支。

如果您同时使用[合并请求管道和分支管道],则可能会同时运行重复的管道。为了防止重复管道,请使用 CI_OPEN_MERGE_REQUESTS 变量。

使用workflow:rules您可以对整个管道执行此操作,但相同的原则也可以应用于单个作业。

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - if: '$CI_COMMIT_BRANCH'

Run Code Online (Sandbox Code Playgroud)

这意味着您的管道将运行:

  • 对于合并请求
  • 对于分支管道,除非有开放的合并请求