- GitLab
- 介绍
- 启用调用日志记录
- 定义变量
- 全局插件配置
- GitLab 到 Jenkins 身份验证
- Jenkins 到 GitLab 身份验证
- 詹金斯作业配置
- 参数配置
- Git 配置
- 自由式工作
- 管道作业
- 管道多分支作业
- 作业触发器配置
- 网络挂钩网址
- 自由式和流水线作业
- 管道多分支作业
- 构建状态配置
- 自由式工作
- 脚本或声明性管道作业
- 管道的待定构建状态
- 矩阵/多配置作业
- 高级功能
- 分支过滤
- 推送标签时构建
- 添加注释以合并请求
- 管道作业 - addGitLabMRComment
- 接受合并请求
- 管道作业
- 通过特定 GitLab 连接通知特定项目
- 取消合并请求更新的挂起构建
GitLab
官网地址:GitLab
介绍
此插件允许 GitLab 在提交代码或打开/更新合并请求时触发 Jenkins 中的构建。它还可以将构建状态发送回 GitLab。
启用调用日志记录
要在插件中启用调试日志记录:
- 转到 Jenkins -> Manage Jenkins -> System Log
- 添加新的日志记录器
- 输入 “
GitLab Plugin
” 或任何您想要的名称 - 在下一页上,为 Logger 输入 “
com.dabsquared.gitlabjenkins
”,将日志级别设置为FINEST
,然后保存 - 然后点击你的 GitLab 插件日志,必要时点击 Clear this log,然后使用 GitLab 触发一些动作
- 刷新日志页面,您应该会看到输出
定义变量
当 GitLab 通过插件触发构建时,会根据 GitLab 发送的 JSON 有效负载设置各种环境变量。您可以在整个作业配置中使用这些。可用的变量是:
gitlabBranch
获取提交到 gitlab 仓库的当前分支名,如:test
gitlabSourceBranch
当用户合并分支时,获取要合并的 gitlab 源分支名,如:test
gitlabActionType
获取当前 gitlab 操作类型,如:NOTE
, PUSH
, MERGE
gitlabUserName
获取提交到 gitlab 仓库的用户名称,如:dev_01
gitlabUserUsername
获取提交到 gitlab 仓库的用户用户名
gitlabUserEmail
获取提交到 gitlab 仓库的用户邮箱地址,如:dev_02@sis.sh.cn
gitlabSourceRepoHomepage
获取提交到 gitlab 源仓库地址,如:http://192.168.4.142/gitlab-instance-6495a54f/test
gitlabSourceRepoName
获取提交到 gitlab 源仓库名,如:Test
gitlabSourceNamespace
获取提交到 gitlab 源仓库的命名空间,如:GitLab Instance
gitlabSourceRepoURL
获取提交到 gitlab 源仓库的 URL 地址,如:git@192.168.4.142:gitlab-instance-6495a54f/test.git
gitlabSourceRepoSshUrl
获取提交到 gitlab 源仓库的 SSH URL 地址,如:git@192.168.4.142:gitlab-instance-6495a54f/test.git
gitlabSourceRepoHttpUrl
获取提交到 gitlab 源仓库的 HTTP URL 地址,如:http://192.168.4.142/gitlab-instance-6495a54f/test.git
gitlabMergeRequestTitle
获取合并分支请求时的标题,如:Update hello.sh
gitlabMergeRequestDescription
获取合并分支请求时的描述信息,如:Update hello.sh
gitlabMergeRequestId
获取合并分支请求时的 ID,如:7
gitlabMergeRequestIid
获取合并分支请求时的 I ID,如:7
gitlabMergeRequestState
获取合并分支请求的状态
gitlabMergedByUser
获取合并分支的用户名
gitlabMergeRequestAssignee
获取合并分支请求时的受让人
gitlabMergeRequestLastCommit
获取合并分支请求时的源分支最后的 commit id
gitlabMergeRequestTargetProjectId
获取合并分支请求时的目标项目 ID
gitlabTargetBranch
当用户合并分支时,获取要合并的 gitlab 目标分支名,如:test
gitlabTargetRepoName
获取提交到 gitlab 目标仓库名,如:Test
gitlabTargetNamespace
获取提交到 gitlab 目标仓库的命名空间,如:GitLab Instance
gitlabTargetRepoSshUrl
获取提交到 gitlab 目标仓库的 SSH URL 地址,如:git@192.168.4.142:gitlab-instance-6495a54f/test.git
gitlabTargetRepoHttpUrl
获取提交到 gitlab 源仓库的 HTTP URL 地址,如:http://192.168.4.142/gitlab-instance-6495a54f/test.git
gitlabBefore
gitlabAfter
gitlabTriggerPhrase
获取触发 gitlab 构建 Jenkins 的语句
注意:这些变量在 Pipeline Multibranch 作业中不可用。
全局插件配置
GitLab 到 Jenkins 身份验证
默认情况下,插件将要求为从 GitLab 到 Jenkins 的连接设置身份验证,以防止未经授权的人员能够触发作业。
- 身份验证安全
APITOKENS 和其他机密不得通过不安全的连接发送。因此,所有连接都应该使用 HTTPS。
注意:使用 LetsEncrypt 可以免费且轻松地管理证书。
- 配置全局认证
- 在 Jenkins 中创建一个至少具有 Job/Build 权限的用户
- 以该用户身份登录(即使您是 Jenkins 管理员用户也是必需的),然后单击页面右上角的用户名
- 单击 “配置”,然后单击 “显示 API 令牌…”,并记下/复制用户 ID 和 API 令牌
- 在 GitLab 中,当您创建 webhook 以触发 Jenkins 作业时,请使用此格式作为 URL,并且不要为 “秘密令牌” 输入任何内容:
https://USERID:APITOKEN@JENKINS_URL/project/YOUR_JOB
- 添加 webhook 后,单击 “测试” 按钮,它应该会成功
- 配置每个项目的身份验证
如果要为每个 Jenkins 作业创建单独的身份验证凭据:
- 在 Jenkins 作业的配置中,在 GitLab 配置部分中,单击 “高级”
- 单击 “秘密令牌” 字段下的 “生成” 按钮
- 复制生成的令牌,并保存作业配置
- 在 GitLab 中,为您的项目创建一个 webhook,输入触发 URL(例如:
https://JENKINS_URL/project/YOUR_JOB
)并将令牌粘贴到Secret Token
字段中 - 添加 webhook 后,单击 “测试” 按钮,它应该会成功
- 禁用身份验证
如果要禁用此身份验证(不推荐):
- 在 Jenkins 中,转到 Manage Jenkins -> Configure System
- 向下滚动到标有 “GitLab” 的部分
- 取消选中 “为 ‘/project’ 端点启用身份验证” - 您现在可以从 GitLab 触发 Jenkins 作业,而无需身份验证
Jenkins 到 GitLab 身份验证
请注意:此身份验证配置仅用于访问 GitLab API 以将构建状态发送到 GitLab。它不用于克隆 git repos。用于克隆的凭据(通常是 SSH 凭据)应在 git 插件中单独配置。
该插件可以配置为向 GitLab 发送构建状态消息,这些消息显示在 GitLab 合并请求 UI 中。要启用此功能:
- 在 GitLab 中创建一个新用户
- 在您希望 Jenkins 向其发送构建状态的每个存储库上授予此用户 “维护者” 权限
- 在 GitLab 中登录或 “模拟” 该用户,单击用户的图标/头像并选择设置
- 点击 “访问令牌”
- 创建一个名为 “jenkins” 的令牌,其范围为 “api”;过期是可选的
- 立即复制 token,离开此页面后无法访问
- 在 Jenkins 的 Global Configuration 页面的 GitLab 配置部分,提供 GitLab 主机 URL,例如:
https://your.gitlab.server
- 单击 “添加” 按钮添加凭证,选择 “GitLab API 令牌” 作为凭证类型,然后将 GitLab 用户的 API 密钥粘贴到 “API 令牌” 字段中
- 单击 “测试连接” 按钮;它应该成功
詹金斯作业配置
在使用 GitLab 触发作业时,您可能需要修改 Jenkins 作业的两个方面。第一个是 Git 配置,Jenkins 在其中克隆您的 git 存储库。GitLab 插件会在 GitLab 触发构建时设置一些环境变量,您可以使用这些变量来控制从 Git 克隆的代码。第二个是将构建状态发送回 GitLab 的配置,它将在提交合并或合并请求 UI 中可见。
参数配置
如果您希望能够通过 GitLab webhook 手动和自动运行作业,则需要为这些作业配置参数。如果您只想从 GitLab 触发作业,则可以跳过此部分。
您创建的任何 GitLab 参数将始终优先于 webhook 发送的值,除非您使用 EnvInject 插件将 webhook 值映射到作业参数。这是为解决安全漏洞而进行的更改。
在您的作业配置中,单击 “此构建已参数化” 并添加您要使用的任何参数。请参阅 定义的变量 列表以获取选项 - 您的参数名称必须与这些 .e.g sourceBranch
和 targetBranch
下面的示例 Groovy 脚本匹配。然后,安装 EnvInject 后,单击 “为运行准备环境” 并检查:
- 保留 Jenkins 环境变量
- 保留 Jenkins 构建变量
- 覆盖构建参数
在 Groovy Script 字段中插入类似于以下内容的内容:
def env = currentBuild.getEnvironment(currentListener)
def map = [:]
if (env.gitlabSourceBranch != null) {
map['sourceBranch'] = env.gitlabSourceBranch
}
if (env.gitlabTargetBranch != null) {
map['targetBranch'] = env.gitlabTargetBranch
}
return map
然后,您可以在作业配置中引用这些变量,例如:${sourceBranch}
。每当您添加或删除参数时,您都需要更新此代码。
注意:如果您使用 Groovy Sandbox,您可能需要自己批准脚本或让管理员在 Jenkins 配置中批准脚本。
Git 配置
自由式工作
在源代码管理部分:
- 点击 “Git”
- 输入您的 “存储库 URL”,例如:
git@your.gitlab.server:gitlab_group/gitlab_project.git
- 在高级设置中,将
Name
设置为origin
,将Refspec
设置为+refs/heads/*:refs/remotes/origin/*
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
- 在 “分支说明符” 中输入:
- 对于单存储库工作流程:
origin/${gitlabSourceBranch}
- 对于分叉的存储库工作流程:
merge-requests/${gitlabMergeRequestIid}
- 在其他行为中:
- 单击 “添加” 下拉按钮
- 从下拉列表中选择 “在构建之前合并”
- 将 “存储库名称” 设置为
origin
- 将 “分支设置为合并” 为
${gitlabTargetBranch}
管道作业
当您使用来自 SCM 的流水线脚本时,Jenkins 流水线错误将阻止 Git 克隆工作。如果您使用 Jenkins 作业配置 UI 来编辑脚本,它就可以工作。这里提到了一种解决方法:https://issues.jenkins-ci.org/browse/JENKINS-33719
使用 Snippet 生成器,General SCM 步骤,为 git checkout/merge 等生成示例 Groovy 代码。
在构建之前执行合并的示例:
checkout changelog: true, poll: true, scm: [
$class: 'GitSCM',
branches: [[name: "origin/${env.gitlabSourceBranch}"]],
extensions: [[$class: 'PreBuildMerge', options: [fastForwardMode: 'FF', mergeRemote: 'origin', mergeStrategy: 'DEFAULT', mergeTarget: "${env.gitlabTargetBranch}"]]],
userRemoteConfigs: [[name: 'origin', url: 'git@gitlab.example.com:foo/testrepo.git']]
]
管道多分支作业
注意:无法将外部数据从 GitLab 传递到 Pipeline Multibranch 作业,因此不会为此作业类型填充 GitLab 环境变量。GitLab 只会触发 Jenkins 项目的分支索引,而 Jenkins 将相应地构建分支,而不需要例如:
git branch env var
。因此,该插件只监听 GitLab Push Hooks 以进行多分支管道作业;合并请求挂钩被忽略。
- 点击 “添加来源”
- 选择 Git
- 输入您的 “存储库 URL”(例如:
git@your.gitlab.server:group/repo_name.git
)
多分支管道作业示例 Jenkinsfile:
// Reference the GitLab connection name from your Jenkins Global configuration (https://JENKINS_URL/configure, GitLab section)
properties([gitLabConnection('your-gitlab-connection-name')])
node {
checkout scm // Jenkins will clone the appropriate git branch, no env vars needed
// Further build steps happen here
}
作业触发器配置
网络挂钩网址
当您配置插件以触发您的 Jenkins 作业时,根据作业类型按照以下说明进行操作,它将侦听来自 GitLab 的 webhook 的 JSON POST 的专用 URL。该 URL 始终采用 https://JENKINS_URL/project/PROJECT_NAME
形式,或者 https://JENKINS_URL/project/FOLDER/PROJECT_NAME
如果项目位于 Jenkins 的文件夹中。您不应该使用 https://JENKINS_URL/job/PROJECT_NAME/build
或 https://JENKINS_URL/job/gitlab-plugin/buildWithParameters
,因为这将完全绕过插件。
自由式和流水线作业
- 在构建触发器部分:
- 将更改推送到 GitLab 时选择 “构建”
- 复制 UI 中显示的 “GitLab Webhook URL”
- 使用复选框触发 “推送事件” 或 “创建的合并请求事件” 或 “接受的合并请求事件” 或 “关闭的合并请求事件” 的构建
- 可以选择使用
Rebuild open Merge Requests
在推送到源分支后启用重新构建打开的合并请求 - 如果您选择了
Rebuild open Merge Requests
而不是None
,请检查Comments
并指定Comment
以触发构建。当此短语出现在提交评论中时,将触发新的构建。除了文字短语,您还可以指定 Java 正则表达式 - 您可以 “在成功的管道事件上使用构建” 来触发在 GitLab 中成功运行的管道。请注意,此构建触发器只会在提交尚未构建且未设置 GitLab 状态时触发构建。否则你可能会陷入循环
- 根据需要配置任何其他预构建、构建或构建后操作
- 单击 “保存” 以保存您在 Jenkins 中的更改
- 在相关的 GitLab 项目中创建一个 webhook(有关这方面的说明,请参阅 GitLab 文档),并使用您从 Jenkins 作业配置 UI 复制的 URL。它应该看起来像
https://JENKINS_URL/project/yourbuildname
管道多分支作业
与其他作业类型不同,多分支作业配置不需要 “触发器” 设置;只需在 GitLab 中为指向项目的 webhook URL 的推送请求创建一个 webhook。当 GitLab 发布到这个 URL 时,它将触发 Jenkins 项目的分支索引,并且 Jenkins 将处理启动任何必要的构建。
如果您想配置一些触发选项,例如:秘密令牌或 CI 跳过功能,您可以使用一个 properties 步骤。例如:
// Define your secret project token here
def project_token = 'abcdefghijklmnopqrstuvwxyz0123456789ABCDEF'
// Reference the GitLab connection name from your Jenkins Global configuration (https://JENKINS_URL/configure, GitLab section)
properties([
gitLabConnection('your-gitlab-connection-name'),
pipelineTriggers([
[
$class: 'GitLabPushTrigger',
branchFilterType: 'All',
triggerOnPush: true,
triggerOnMergeRequest: false,
triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
secretToken: project_token,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",
]
])
])
构建状态配置
您可以选择让您的 Jenkins 作业将其构建状态发送回 GitLab,它将在提交或合并请求 UI 中酌情显示。
自由式工作
使用 “将构建状态发布到 GitLab” 构建后操作将具有给定构建名称的构建状态发送回 GitLab。触发构建时发送 Pending
构建状态,构建开始时发送 Running
状态,构建完成后发送 Success
或 Failed
状态。
如果您有多个,请确保您从 “GitLab 连接” 下拉菜单中选择了适当的 GitLab 实例。
脚本或声明性管道作业
注意:如果您使用 Pipeline 全局库,或者如果您从与包含相关源代码的存储库不同的存储库中克隆项目的 Jenkinsfile,则在发送项目状态时需要小心。简而言之,确保将您的
gitlabCommitStatus
或其他类似的步骤放在克隆项目源代码的 SCM 步骤之后。否则,您可能会收到 HTTP 400 错误,或者您可能会发现构建状态被发送到错误的存储库。
- 脚本化管道作业
对于流水线作业,使用如下步骤围绕您的构建步骤 gitlabCommitStatus:
node() {
stage('Checkout') { checkout <your-scm-config> }
gitlabCommitStatus {
// 此块中步骤的结果将被发送到 GitLab
sh 'mvn install'
}
}
或者使用该 updateGitlabCommitStatus
步骤使用自定义值来更新提交状态。您可以使用 try/catch
块或其他逻辑将构建的细粒度状态发送到 GitLab。有效状态由 GitLab 定义并在此处记录:https://docs.gitlab.com/ce/api/pipelines.html
node() {
stage('Checkout') { checkout <your-scm-config> }
updateGitlabCommitStatus name: 'build', state: 'pending'
// Build steps
updateGitlabCommitStatus name: 'build', state: 'success'
}
或者,您可以使用以下步骤在 GitLab 中将多个构建阶段标记为待处理 gitlabBuilds:
node() {
stage('Checkout') { checkout <your-scm-config> }
gitlabBuilds(builds: ["build", "test"]) {
stage("build") {
gitlabCommitStatus("build") {
// your build steps
}
}
stage("test") {
gitlabCommitStatus("test") {
// your test steps
}
}
}
}
注意:如果将 gitlabBuilds 块放在节点块中,则在分配节点之前不会触发。在繁忙的系统上,或者节点是按需分配的系统上,这里可能会有延迟,并且 “待定” 状态不会立即发送到 GitLab。如果这是一个问题,您可以移动 gitlabBuilds 块以包裹节点块,然后当 Jenkins 开始尝试分配节点时将发送状态。
- 声明性管道职位
下面的示例配置 GitLab 连接和作业触发器。它还将构建状态发送回 GitLab。
注意:您需要手动运行一次此作业,以便 Jenkins 读取和设置触发器配置。否则 webhook 将无法触发作业。
pipeline {
agent any
post {
failure {
updateGitlabCommitStatus name: 'build', state: 'failed'
}
success {
updateGitlabCommitStatus name: 'build', state: 'success'
}
}
options {
gitLabConnection('your-gitlab-connection-name')
}
triggers {
gitlab(triggerOnPush: true, triggerOnMergeRequest: true, branchFilterType: 'All')
}
stages {
stage("build") {
steps {
echo "hello world"
}
}
}
[...]
}
如果:
- 您对 GitLab 中的合并请求使用 “管道成功时合并” 选项,并且
- 您的声明式管道作业有多个阶段,并且
- 您在每个阶段
gitlabCommitStatus
使用一个步骤将状态发送到 GitLab…
然后:您将需要在一个 options
块中定义这些阶段。否则,当第一阶段通过时,GitLab 将合并更改。例如:如果您有名为 build、test 和 deploy 的三个阶段:
options {
gitLabConnection('your-gitlab-connection-name')
gitlabBuilds(builds: ['build', 'test', 'deploy'])
}
如果要配置插件在声明式构建中支持的任何可选作业触发器,请使用 triggers
块。可配置触发选项的完整列表如下:
triggers {
gitlab(
triggerOnPush: false,
triggerOnMergeRequest: true, triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",
pendingBuildName: "Jenkins",
cancelPendingBuildsOnUpdate: false,
secretToken: "abcdefghijklmnopqrstuvwxyz0123456789ABCDEF")
}
管道的待定构建状态
要在触发管道时向 GitLab 发送 “待处理” 构建状态,请在触发器配置的 “高级” 部分中将构建名称设置为 “管道的待处理构建名称” 字段,或在声明中的 GitLab 触发器配置中使用 pendingBuildName
选项管道。
矩阵/多配置作业
该插件可以与矩阵/多配置作业一起使用,Flexible Publish 插件允许您在所有轴作业完成后运行发布者。如下配置 “构建后操作”:
- 添加 “Flexible Publish” 操作
- 在 “Flexible Publish” 部分:
- 添加 “条件” 操作
- 在 “条件操作” 部分:
- 设置 “Run? to Never”
- 选择 “矩阵聚合的条件”
- 设置 “Run on Parent? to Always”
- 根据需要添加 GitLab 操作
高级功能
分支过滤
可以根据分支名称过滤触发器,即只允许对选定的分支进行构建。在项目配置页面上,当您配置 GitLab 触发器时,您可以选择 “按名称过滤分支” 或 “按正则表达式过滤分支”。按名称过滤采用逗号分隔的分支名称列表,以包括或排除触发构建。按正则表达式过滤采用 Java 正则表达式来包含或排除。
注意:此功能需要访问 GitLab 和已保存在项目配置中的 git 存储库 url。也就是说,在新建项目时,需要先保存一次配置,然后才能添加分支过滤器。对于管道作业,必须保存配置并且必须在填充列表之前运行一次作业。
推送标签时构建
为了在推送新标签时进行构建:
- 在 GitLab webhook 配置中,添加 “标签推送事件”
- 在 “源代码管理” 下的作业配置中:
- 选择 “高级…” 并添加 “
+refs/tags/*:refs/remotes/origin/tags/*
” 作为 Refspec - 您还可以使用 ‘Branch Specifier’ 来指定需要构建的标签(例如:‘
refs/tags/${TAGNAME}
’)
添加注释以合并请求
要在构建完成后向 GitLab 合并请求添加注释,请从可选的构建后操作中选择 “在 GitLab 合并请求上添加带有构建状态的注释”。或者,单击 “高级” 按钮以根据构建结果自定义注释的内容。
管道作业 - addGitLabMRComment
addGitLabMRComment(comment: 'The pipeline was run on Jenkins')
请注意,它要求构建由 GitLab MR webhook 触发,而不是 push webhook(或手动构建)。另请注意,它目前不适用于 “多分支管道作业”,因为 MR 挂钩不会触发。
接受合并请求
要在构建完成时接受合并请求,请从可选的构建后操作中选择 “成功接受 GitLab 合并请求”。
管道作业
对于流水线作业,可以提供两个高级配置选项
useMRDescription
- 将合并请求描述添加到合并提交中,其格式与通过在 GitLab UI 中选择 “修改提交消息” 后跟 “提交消息中包含描述” 所接收的格式相似removeSourceBranch
- 当合并请求被接受时删除 GitLab 中的源分支acceptGitLabMR(useMRDescription: true, removeSourceBranch: true)
通过特定 GitLab 连接通知特定项目
您可以指定项目构建的地图以通知可能位于不同服务器上的各种 GitLab 存储库。如果您想创建涉及多个 Jenkins 和 GitLab 项目的复杂 CI/CD,这将非常有用,请参见以下示例:
- 使用触发器上下文中的 GitLab 连接数据通知多个 GitLab 项目:
gitlabCommitStatus(name: 'stage1',
builds: [
[projectId: 'test/test', revisionHash: 'master'],
[projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
- 使用特定 GitLab 连接通知多个 GitLab 项目:
gitlabCommitStatus( name: 'stage1', connection:gitLabConnection('site1-connection'),
builds: [
[projectId: 'test/test', revisionHash: 'master'],
[projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
- 通知位于不同 GitLab 服务器上的多个 GitLab 存储库:
gitlabCommitStatus(
builds: [
[name:'stage1',connection:gitLabConnection('site1-connection'), projectId: 'group/project1', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'), projectId: 'group/project1', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'), projectId: 'test/test', revisionHash: 'master'],
[name:'stage1',connection:gitLabConnection('site2-connection'), projectId: 'test/utils', revisionHash: 'master'],
])
{
echo 'Hello World'
}
取消合并请求更新的挂起构建
要在推送新提交时取消同一合并请求的挂起构建,请从触发器配置的高级部分中选中 “取消挂起的合并请求更新时构建”。这可以节省项目的时间,在这些项目中,构建可以在构建队列中停留很长时间,而您只关心最新提交的状态。