Gitlab CI。在主分支构建期间获取合并请求 ID答案

【问题标题】：GitlabCI. Get merge request ID during master branch buildGitlab CI。在主分支构建期间获取合并请求 ID
【发布时间】：2023-01-21 15:26:04
【问题描述】：

每次合并新的拉取请求时，都会构建 master 分支。在此阶段执行这些步骤：

创建了一个新的 Git 标签（版本自动递增）。
库已发布到注册表。
一封新电子邮件将发送给所有正在跟踪新版本的用户。
我想将直接链接添加到已合并并在邮件中触发此版本的合并请求。虽然我可以在合并请求构建过程中获得 the information（MR ID），但我不明白一旦 MR 被合并我该如何检索它。

有什么方法可以克服这个问题吗？

【问题讨论】：

标签： gitlab continuous-integration devops gitlab-ci

【解决方案1】：

我设法发现的唯一方法是通过REST API 请求合并请求。在这种情况下，我可以按状态和创建日期过滤它们。所以最新的merged一个就是我需要的MR。

这是一个假设的查询：

/api/v4/projects/:projectId/merge_requests?state=merged&created_after=:day_before_now

接收到的数组中的第一个合并请求是目标请求。

附言created_after=:day_before_now 属性只是减少了 HTTP 接收的数据量。您可以省略它并且不会改变行为。

【讨论】：

【解决方案2】：

我刚刚解决了与此类似的问题，每个人都建议使用 API，而我正在为我的管道使用 API。

我的管道有两个阶段：第一阶段第二阶段

Stage1 is triggered when MR is created (MR status: open)
Stage2 is triggered when MR (MR status: open) is merged (MR status: merged)

现在的问题是这两个阶段是在不同的管道中触发的。不同的管道意味着 GitLab 的所有可变世界仅限于管道本身。什么都没有出去。

然后我用gitlab API. Stage1 将获取 api 列表中第一个最新的开放合并请求 ID，这显然是触发 Stage1 的 MR。由于 Stage1 管道在 MR 的状态变为“打开”时立即开始执行，因此它始终位于打开 MR 列表的顶部。

我通过获取第一个最新的“合并”合并请求 ID 为 Stage2 所做的相同。一切正常，但使用 api 的问题是时间:(

它有一个窗口，当 gitlab api 使用新的最新合并 id 更新并且您的 Stage1 尚未从 gitlab api 获取合并 id 时，可能会出现问题，无论何时它都会获得合并 id 的新值。这个问题适用于使用 gitlab api 作为合并 ID 的两个阶段。

由于这两个阶段在不同的管道中，他们正在为它们旋转单独的 docker 容器，这一次窗口直到阶段将执行并从 gitlab api 获取合并 id 是问题所在。

所以 gitlab api 数据在这种情况下是不可靠的。然后我转向了gitlab的可变世界。

我从变量 CI_MERGE_REQUEST_IID 获得了 Stage1 中的合并 ID

第一阶段很好。

现在，Stage2 在新管道中运行，并且该管道显示 CI_MERGE_REQUEST_IID 为空。在检查了尽可能多的 CI 变量的值后，我发现我最终在 GitLab 中使用了 export 命令。

我在 .gitlab-ci.yml 中添加了export：

  script:
    - export

export把所有东西都交出来了！！

export 命令给出了所有变量及其值的列表，可供当前管道中的阶段使用。

我比较了 Satge1 和 Satge2 的变量列表。然后我发现

CI_COMMIT_MESSAGE

虽然它的价值不同在两个阶段之间，我发现合并编号在其中用于 Stage2。

所以对于我的问题，这是只要新管道中可用的变量有一些参考合并 id 并在 Stage2 的这个新管道的变量世界中可用。

尽管管线不同，但它们连接到相同的合并请求并在其不同事件上触发，例如

merge_request_status = "open"

merge_request_status = "merged"

默认情况下 CI_COMMIT_MESSAGE 的值为：

Merge branch '%{source_branch}' into '%{target_branch}'

%{title}

%{issues}

See merge request %{reference}

此消息来自默认模板 (more info)。

%{reference} 默认模板中的变量的值是合并 ID 的路径。所以我从 CI_COMMIT_MESSAGE 中切出了合并的 id

merge_id=$(echo $CI_COMMIT_MESSAGE|awk -F! '{print $2}')

所以现在我的两个管道都在变量中提供合并 id，供两个阶段使用。所以现在管道不再依赖于来自 gitlab api 的第一条信息。相反，现在他们已经有了合并 ID，他们可以从中浏览它下面的所有内容，如管道、提交、作业等，使用 gitlab api 很容易，数据是可靠的。

merge id 是一种父变量，它连接到所有管道、提交、作业等，同时使用 gitlab api 获取数据，并且在 merged MR 事件中很难找到该变量是可悲的。这是一个重要的变量，应该在触发管道的所有类型的事件中可用。

希望这可以帮助。

【讨论】：

【解决方案3】：

使用 API 获取最新的合并管道，就像接受的答案所建议的那样，是一个好主意，但它不是万无一失的：如果快速合并多个 MR，您正在寻找的可能不是最新的。

幸运的是，我认为有一个更简单的解决方案：查看最新的提交消息。只要确保在你的项目设置中，你有合并提交的默认模板：见Gitlab doc。

您的最新提交将如下所示：

commit 20780d95bd026e04d409d5c47c045915c6883333
Merge: e4368ba 4hfa518
Author: My Name <my-email>
Date:   Some-Timestamp

    Merge branch 'my-branch' into 'main'
    
    My commit message
    
    See merge request my-group/my-project!52

这里MR iid为52；然后您可以轻松地自动抓取它。

暂定实施：我不是 regex/glob 向导，但我认为这可行：

matched_line="$(git log -1 --pretty=%B | grep 'See merge request')"
mr_iid=${matched_line##*!}

【讨论】：