Question

在我的管道中，仅当Merge Requests目标分支是某个分支（例如master或release）时，我才希望运行作业。

这可能吗？

我已经阅读了https://docs.gitlab.com/ee/ci/variables/，除非我错过了任何东西，否则我看不到任何可以帮助您的东西。

Answer 1

更新时间：2019-03-21

GitLab自版本11.6起具有用于合并请求信息的变量（https://docs.gitlab.com/ce/ci/variables/请参见以CI_MERGE_REQUEST_开头的变量）。但是，这些变量仅在merge request pipelines中可用。（https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html）

要为合并请求配置CI作业，我们必须在要合并请求的作业上设置only: merge_request。然后，我们可以在这些作业中使用CI_MERGE_REQUEST_*变量。

这里最大的陷阱是 only: merge_request与普通的only/except参数完全不同。

通常的only/except参数：（https://docs.gitlab.com/ce/ci/yaml/README.html#onlyexcept-basic）

only定义了要为其运行作业的分支和标签的名称。

except定义了作业将无法运行的分支和标签的名称。

only: merge_request：（https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html#excluding-certain-jobs）

only: merge_requests参数的行为使得只有具有该参数的作业才在合并请求的上下文中运行；没有其他作业可以运行。

我很难重组工作以使其像以前一样工作，only: merge_request在任何工作中都存在。因此，我仍在原始答案中使用单线以在CI作业中获取MR信息。

原始答案：

否。

但是GitLab计划在2019年第二季度对此功能进行计划：https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#final-assumptions

当前，我们可以使用一种解决方法来实现这一目标。该方法如Rekovni的答案所述，并且确实有效。

有一个简单的单行代码，从当前分支获取MR的目标分支：

script: # in any script section of gitlab-ci.yml
  - 'CI_TARGET_BRANCH_NAME=$(curl -LsS -H "PRIVATE-TOKEN: $AWESOME_GITLAB_API_TOKEN" "https://my.gitlab-instance.com/api/v4/projects/$CI_PROJECT_ID/merge_requests?source_branch=$CI_COMMIT_REF_NAME" | jq --raw-output ".[0].target_branch")'

说明：

CI_TARGET_BRANCH_NAME是一个新定义的变量，用于存储解析的目标分支名称。定义变量对于各种用法不是必需的。

AWESOME_GITLAB_API_TOKEN是在存储库的CI / CD变量配置中配置的变量。这是一个具有api范围的GitLab个人访问令牌（在“用户设置”中创建）。

关于curl选项：-L使curl知道HTTP重定向。 -sS使curl静音（-s）但显示（-S）错误。 -H指定访问GitLab API的权限信息。

可以在https://docs.gitlab.com/ce/api/merge_requests.html#list-project-merge-requests中建立使用的API。我们使用source_branch属性来确定正在运行的MR当前管道。因此，如果源分支具有到不同目标分支的多个MR，则您可能想要更改|之后的部分并执行自己的逻辑。

关于jq（https://stedolan.github.io/jq/），这是一个处理JSON内容（GitLab API返回的内容）的简单CLI实用程序。您可以使用node -p或任何所需的方法。

Answer 2

如果这是您真正想要的，那么可能会有一种极其复杂的方法（未经测试），您可以使用merge request API和CI variables来实现。

在工作流程/构建步骤中，类似：

创建从feature/test到master的合并请求
开始构建
使用API（在脚本中），使用CI_PROJECT_ID变量抓取当前项目中的所有打开的合并请求，并按source_branch和target_branch进行过滤。
如果打开的合并请求中source_branch和target_branch分别为feature/test和master，则继续构建，否则跳过其余构建。

对于使用API，我不相信您可以使用CI_JOB_TOKEN变量进行身份验证，因此您可能需要创建自己的personal access token并将其存储为{{3} }用于构建作业。

希望这会有所帮助！

Answer 3

由于11.6中的new env variables，$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME和$CI_MERGE_REQUEST_TARGET_BRANCH_NAME作业可以根据源分支或目标分支来包括或排除。

使用only and except (complex)表达式，我们可以构建规则来过滤合并请求。举几个例子：

合并请求，目标分支为master：

only:
    refs:
        - merge_requests
    variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

合并请求，除非源分支是master 或 release：

only:
    - merge_requests
except:
    variables:
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "master"
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "release"

如果您要使用多个引用（例如merge_requests和标签）和多个变量，则将对这些引用进行OR，the variables will be OR'd和the result will be AND'd：

如果仅使用变量时变量中的任何条件得出真值，将创建一个新作业。如果在使用except时，如果任何表达式的计算结果为真，则将不会创建作业。

如果仅在“或”下使用多个键，则它们将用作AND。逻辑是：
(any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)

变量表达式也很原始，仅支持相等和（基本）正则表达式。由于变量将是OR'd，因此从gitlab 11.6开始，您既不能同时指定源分支又要指定目标分支。

Answer 4

Gitlab CI与合并请求无关（目前）。由于管道在Origin分支上运行，因此您将无法检索目标。

Answer 5

从GitLab 11.6开始，有CI_MERGE_REQUEST_TARGET_BRANCH_NAME。

在GitLab CI中，合并请求的目标分支是否有变量？

5 个答案: