环境

极狐GitLab 环境代表应用程序的特定部署目标，如开发、暂存或生产。使用它来管理不同的配置，并在软件生命周期的各个阶段部署代码。

使用环境，您可以：

• 保持部署过程的一致性和可重复性
• 跟踪代码部署的位置
• 在出现问题时回滚到以前的版本
• 保护敏感环境免受未经授权的更改
• 控制每个环境的部署变量以维护安全边界
• 监控环境健康状况，并在出现问题时收到警报

查看环境和部署#

先决条件：

• 在私有项目中，您至少需要拥有 Reporter 角色。请参阅 环境权限。

有几种方法可以查看给定项目的环境列表：

• 在项目的概览页面上，如果至少有一个环境可用（即未停止）。

  

• 在左侧边栏，选择 运维 > 环境。 环境会显示出来。

  

• 要查看某个环境的部署列表，请选择环境名称，例如 staging。

  

  只有在部署作业创建了它们之后，部署才会显示在此列表中。

• 要查看部署流水线中的所有手动作业列表，请选择 Run (

  ) 下拉列表。

  

环境 URL#

环境 URL 在极狐GitLab 中的几个地方显示：

• 在合并请求中作为链接：

  

• 在环境视图中作为按钮：

  

• 在部署视图中作为按钮：

  

如果满足以下条件，您可以在合并请求中查看此信息：

• 合并请求最终合并到默认分支（通常是 main）。
• 该分支还部署到某个环境（例如 staging 或 production）。

例如：

从源文件到公共页面#

借助极狐GitLab 的 Route Maps，您可以直接从源文件跳转到为审阅应用设置的环境中的公共页面。

环境类型#

环境可以是静态的或动态的。

静态环境：

• 通常由连续的部署重用。
• 具有静态名称。例如，staging 或 production。
• 手动创建或作为 CI/CD 流水线的一部分创建。

动态环境：

• 通常在 CI/CD 流水线中创建，仅由一个部署使用，然后停止或删除。
• 具有动态名称，通常基于 CI/CD 变量的值。
• 是 审阅应用 的一项功能。

环境具有三种状态之一，具体取决于其 停止作业 是否已运行：

• available：环境存在。可能有一个部署。
• stopping：on stop job 已启动。当没有定义停止作业时，此状态不适用。
• stopped：要么 on stop job 已运行，要么用户手动停止了作业。

创建静态环境#

您可以在 UI 或 .gitlab-ci.yml 文件中创建静态环境。

在 UI 中#

先决条件：

• 您至少需要拥有 Developer 角色。

要在 UI 中创建静态环境：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 选择 创建环境。
4. 完成字段。
5. 选择 保存。

在您的 .gitlab-ci.yml 文件中#

先决条件：

• 您至少需要拥有 Developer 角色。

要在您的 .gitlab-ci.yml 文件中创建静态环境：

1. 在 deploy 阶段定义一个作业。
2. 在作业中定义环境 name 和 url。如果在流水线运行时不存在具有该名称的环境，则会创建它。

例如，要创建名为 staging 的环境，并使用 URL https://staging.example.com：

yaml
1deploy_staging:
2  stage: deploy
3  script:
4    - echo "Deploy to staging server"
5  environment:
6    name: staging
7    url: https://staging.example.com

创建动态环境#

要创建动态环境，您需要使用独特于每个流水线的 CI/CD 变量。

先决条件：

• 您至少需要拥有 Developer 角色。

要在您的 .gitlab-ci.yml 文件中创建动态环境：

1. 在 deploy 阶段定义一个作业。
2. 在作业中定义以下环境属性：
   • name：使用相关的 CI/CD 变量，如 $CI_COMMIT_REF_SLUG。可选地，为环境名称添加静态前缀，在 UI 中分组 所有具有相同前缀的环境。
   • url：可选。使用相关的 CI/CD 变量，如 $CI_ENVIRONMENT_SLUG 为主机名添加前缀。

在以下示例中，每次运行 deploy_review_app 作业时，环境的名称和 URL 都使用唯一值定义。

yaml
1deploy_review_app:
2  stage: deploy
3  script: make deploy
4  environment:
5    name: review/$CI_COMMIT_REF_SLUG
6    url: https://$CI_ENVIRONMENT_SLUG.example.com
7  rules:
8    - if: $CI_COMMIT_BRANCH == "main"
9      when: never
10    - if: $CI_COMMIT_BRANCH

设置动态环境 URL#

一些外部托管平台为每次部署生成一个随机 URL，例如：https://94dd65b.amazonaws.com/qa-lambda-1234567。这使得在 .gitlab-ci.yml 文件中引用 URL 变得困难。

为了解决这个问题，您可以配置一个部署作业以报告一组变量。这些变量包括由外部服务动态生成的 URL。极狐GitLab 支持 dotenv (.env) 文件格式，并使用 .env 文件中定义的变量扩展 environment:url 值。

要使用此功能，请在 .gitlab-ci.yml 中指定 artifacts:reports:dotenv 关键字。

您还可以在 environment:url 中指定 URL 的静态部分，例如 https://$DYNAMIC_ENVIRONMENT_URL。如果 DYNAMIC_ENVIRONMENT_URL 的值为 example.com，则最终结果为 https://example.com。

在 UI 中，分配给 review/your-branch-name 环境的 URL 可见。

有关概述，请参见 Set dynamic URLs after a job finished。

在以下示例中，审阅应用为每个合并请求创建一个新环境：

• review 作业由每次推送触发，并创建或更新名为 review/your-branch-name 的环境。环境 URL 设置为 $DYNAMIC_ENVIRONMENT_URL。
• 当 review 作业完成时，极狐GitLab 更新 review/your-branch-name 环境的 URL。它解析 deploy.env 报告产物，将变量列表注册为运行时创建的，扩展 environment:url: $DYNAMIC_ENVIRONMENT_URL 并将其设置为环境 URL。

yaml
1review:
2  script:
3    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # 在脚本中，获取环境 URL。
4    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # 将值添加到 dotenv 文件中。
5  artifacts:
6    reports:
7      dotenv: deploy.env                                                       # 回传 dotenv 文件给 rails。
8  environment:
9    name: review/$CI_COMMIT_REF_SLUG
10    url: $DYNAMIC_ENVIRONMENT_URL                                              # 并将脚本中生成的变量设置为 `environment:url`
11    on_stop: stop_review
12
13stop_review:
14  script:
15    - ./teardown-environment
16  when: manual
17  environment:
18    name: review/$CI_COMMIT_REF_SLUG
19    action: stop

请注意以下几点：

• stop_review 不生成 dotenv 报告产物，因此不识别 DYNAMIC_ENVIRONMENT_URL 环境变量。因此，您不应在 stop_review 作业中设置 environment:url。
• 如果环境 URL 无效（例如，URL 格式错误），系统不会更新环境 URL。
• 如果 stop_review 中运行的脚本仅存在于您的存储库中，因此无法使用 GIT_STRATEGY: none 或 GIT_STRATEGY: empty，请为这些作业配置 合并请求流水线。这可以确保 runner 能够在删除功能分支后仍然提取存储库。有关更多信息，请参阅 Ref Specs for Runners。

powershell
Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"

环境的部署层级#

有时，您可能希望使用代码名称而不是行业标准环境名称，例如 production，您可能想要使用 customer-portal。虽然在技术上没有理由不使用 customer-portal 这样的名称，但该名称不再指示环境用于生产。这可能会影响 部署频率 等指标的计算。

为了表明特定环境用于特定用途，您可以使用层级：

默认情况下，极狐GitLab 会根据 环境名称 假定一个层级。 您无法使用 UI 设置环境层级。 相反，您可以使用 deployment_tier 关键字 来指定层级。

重命名环境#

您无法重命名环境。

要实现与重命名环境相同的结果：

1. 停止现有环境。
2. 删除现有环境。
3. 创建一个具有所需名称的新环境。

CI/CD 变量#

要自定义环境和部署，您可以使用任何 预定义的 CI/CD 变量，并定义自定义 CI/CD 变量。

限制 CI/CD 变量的环境范围#

默认情况下，所有 CI/CD 变量 在流水线中的所有作业中可用。 如果作业中的测试工具受到攻击，该工具可能尝试检索作业可用的所有 CI/CD 变量。为了帮助减轻这种供应链攻击，您应该将敏感变量的环境范围限制为仅需要它们的作业。

通过定义变量可以在哪些环境中可用来限制 CI/CD 变量的环境范围。默认环境范围是 * 通配符，因此任何作业都可以访问该变量。

您可以使用特定匹配来选择特定环境。例如，将变量的环境范围设置为 production 以便仅允许具有 production 环境的作业访问变量。

您还可以使用通配符匹配 (*) 来选择特定环境组，例如所有具有 review/* 的 审阅应用。

例如，有以下四个环境：

• production
• staging
• review/feature-1
• review/feature-2

这些环境范围匹配如下：

您不应使用环境范围变量与 rules 或 include。 在流水线创建时，极狐GitLab 验证流水线配置时可能无法定义这些变量。

搜索环境#

要按名称搜索环境：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 在搜索栏中输入您的搜索词。
   • 搜索词长度应为 3 个或更多字符。
   • 匹配从环境名称的开头开始应用。
     • 例如，devel 匹配环境名称 development，但 elop 不匹配。
   • 对于具有文件夹名称格式的环境，匹配在基本文件夹名称之后应用。
     • 例如，当名称为 review/test-app 时，搜索词 test 匹配 review/test-app。
     • 同时使用文件夹名称前缀搜索，如 review/test 匹配 review/test-app。

分组相似环境#

您可以在 UI 中将环境分组到可折叠部分。

例如，如果您的所有环境都以 review 开头，那么在 UI 中，环境会在该标题下分组：

以下示例显示如何以 review 开始环境名称。变量 $CI_COMMIT_REF_SLUG 在运行时填充分支名称：

yaml
1deploy_review:
2  stage: deploy
3  script:
4    - echo "Deploy a review app"
5  environment:
6    name: review/$CI_COMMIT_REF_SLUG

停止环境#

停止环境意味着其部署在目标服务器上不可访问。必须先停止环境才能删除它。

使用 UI 停止环境#

要在极狐GitLab UI 中停止环境：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 在要停止的环境旁边选择 Stop。
4. 在确认对话框中选择 Stop environment。

默认停止行为#

极狐GitLab 会在关联分支被删除或合并时自动停止环境。即使没有定义显式 on_stop CI/CD 作业，此行为仍然存在。

您可以使用环境 API 中的 auto_stop_setting 参数配置环境的停止行为。

删除分支时停止环境#

您可以配置环境以在删除分支时停止。

在以下示例中，deploy_review 作业调用 stop_review 作业以清理并停止环境。

• 两个作业必须具有相同的 rules 或 only/except 配置。否则，stop_review 作业可能不会包含在包含 deploy_review 作业的所有流水线中，您无法触发 action: stop 以自动停止环境。
• 如果启动环境的作业位于后续阶段，则 action: stop 的作业可能无法运行。
• 如果您无法使用 合并请求流水线，请在 stop_review 作业中设置 GIT_STRATEGY 为 none 或 empty。然后，runner 在删除分支后不会尝试检出代码。

yaml
1deploy_review:
2  stage: deploy
3  script:
4    - echo "Deploy a review app"
5  environment:
6    name: review/$CI_COMMIT_REF_SLUG
7    url: https://$CI_ENVIRONMENT_SLUG.example.com
8    on_stop: stop_review
9
10stop_review:
11  stage: deploy
12  script:
13    - echo "Remove review app"
14  environment:
15    name: review/$CI_COMMIT_REF_SLUG
16    action: stop
17  when: manual

合并或关闭合并请求时停止环境#

使用 合并请求流水线 配置时，自动启用 stop 触发器。

在以下示例中，deploy_review 作业调用 stop_review 作业以清理并停止环境。

• 当 Pipelines must succeed 设置开启时，可以在 stop_review 作业上配置 allow_failure: true 关键字，以防止其阻止您的流水线和合并请求。

yaml
1deploy_review:
2  stage: deploy
3  script:
4    - echo "Deploy a review app"
5  environment:
6    name: review/$CI_COMMIT_REF_SLUG
7    on_stop: stop_review
8  rules:
9    - if: $CI_MERGE_REQUEST_ID
10
11stop_review:
12  stage: deploy
13  script:
14    - echo "Remove review app"
15  environment:
16    name: review/$CI_COMMIT_REF_SLUG
17    action: stop
18  rules:
19    - if: $CI_MERGE_REQUEST_ID
20      when: manual

在特定时间段后停止环境#

您可以设置环境在特定时间段后自动停止。

在您的 .gitlab-ci.yml 文件中，指定 environment:auto_stop_in 关键字。以自然语言指定时间段，例如 1 hour and 30 minutes 或 1 day。 时间段过去后，极狐GitLab 自动触发作业以停止环境。

在以下示例中：

• 每次对合并请求的提交都会触发 review_app 作业，以部署最新更改到环境并重置其过期时间。
• 如果环境在一周内处于非活动状态，极狐GitLab 会自动触发 stop_review_app 作业以停止环境。

yaml
1review_app:
2  script: deploy-review-app
3  environment:
4    name: review/$CI_COMMIT_REF_SLUG
5    on_stop: stop_review_app
6    auto_stop_in: 1 week
7  rules:
8    - if: $CI_MERGE_REQUEST_ID
9
10stop_review_app:
11  script: stop-review-app
12  environment:
13    name: review/$CI_COMMIT_REF_SLUG
14    action: stop
15  rules:
16    - if: $CI_MERGE_REQUEST_ID
17      when: manual

environment:action 关键字可用于重置计划停止环境的时间。有关更多信息，请参阅 出于准备或验证目的访问环境。

查看环境的计划停止日期和时间#

当环境 计划在指定时间段后停止 时，您可以查看其过期日期和时间。

要查看环境的过期日期和时间：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 选择环境的名称。

过期日期和时间显示在左上角，靠近环境的名称。

覆盖环境的计划停止日期和时间#

当环境 计划在指定时间段后停止 时，您可以覆盖其过期时间。

要在 UI 中覆盖环境的过期时间：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 选择环境名称。
4. 在右上角，选择图钉 (
   )。

要在 .gitlab-ci.yml 中覆盖环境的过期时间：

1. 打开项目的 .gitlab-ci.yml。
2. 更新相应部署作业的 auto_stop_in 设置为 auto_stop_in: never。

auto_stop_in 设置被覆盖，环境保持活动状态，直到手动停止。

清理过时环境#

当您想要停止项目中的旧环境时，可以清理过时环境。

先决条件：

• 您至少需要拥有 Maintainer 角色。

要清理过时环境：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 选择 Clean up environments。
4. 选择用于确定哪些环境被视为过时的日期。
5. 选择 Clean up。

在指定日期之后未更新的活动环境将被停止。 受保护环境将被忽略，不会被停止。

环境停止时运行流水线作业#

您可以为环境定义一个停止作业，该作业具有 on_stop 动作 的环境部署作业。

在环境停止时，最新完成流水线中所有完成的部署的停止作业都会运行。部署或流水线的 完成 状态为成功、取消或失败。

先决条件：

• 部署作业和停止作业必须具有相同的规则或仅/排除配置。
• 停止作业必须定义以下关键字：
  • when，在以下任一位置定义：
    • 作业级别。
    • 在规则子句中。如果使用 rules 和 when: manual，您还应该设置 allow_failure: true，以便即使作业未运行，流水线也能完成。
  • environment:name
  • environment:action

在以下示例中：

• review_app 作业在第一个作业完成后调用 stop_review_app 作业。
• stop_review_app 根据 when 定义的内容触发。在这种情况下，它设置为 manual，因此需要极狐GitLab UI 中的 手动操作 来运行。
• 设置 GIT_STRATEGY 为 none。如果 stop_review_app 作业 自动触发，则 runner 在删除分支后不会尝试检出代码。

yaml
1review_app:
2  stage: deploy
3  script: make deploy-app
4  environment:
5    name: review/$CI_COMMIT_REF_SLUG
6    url: https://$CI_ENVIRONMENT_SLUG.example.com
7    on_stop: stop_review_app
8
9stop_review_app:
10  stage: deploy
11  variables:
12    GIT_STRATEGY: none
13  script: make delete-app
14  when: manual
15  environment:
16    name: review/$CI_COMMIT_REF_SLUG
17    action: stop

环境的多个停止动作#

要在环境上配置多个 并行 停止动作，请在同一个 environment 的多个 部署作业 中指定 on_stop 关键字，如 .gitlab-ci.yml 文件中定义。

当环境停止时，只有成功部署作业的匹配 on_stop 动作会并行运行，没有特定顺序。

在以下示例中，对于 test 环境有两个部署作业：

• deploy-to-cloud-a
• deploy-to-cloud-b

当环境停止时，系统会并行运行 on_stop 动作 teardown-cloud-a 和 teardown-cloud-b。

yaml
1deploy-to-cloud-a:
2  script: echo "Deploy to cloud a"
3  environment:
4    name: test
5    on_stop: teardown-cloud-a
6
7deploy-to-cloud-b:
8  script: echo "Deploy to cloud b"
9  environment:
10    name: test
11    on_stop: teardown-cloud-b
12
13teardown-cloud-a:
14  script: echo "Delete the resources in cloud a"
15  environment:
16    name: test
17    action: stop
18  when: manual
19
20teardown-cloud-b:
21  script: echo "Delete the resources in cloud b"
22  environment:
23    name: test
24    action: stop
25  when: manual

不运行 on_stop 动作停止环境#

有时，您可能希望停止环境而不运行定义的 on_stop 动作。例如，您希望删除许多环境而不使用 计算配额。

要停止环境而不运行定义的 on_stop 动作，请执行 停止环境 API，并使用参数 force=true。

删除环境#

当您想要删除环境及其所有部署时，请删除环境。

先决条件：

• 您至少需要拥有 Developer 角色。
• 您必须 停止 环境才能删除它。

要删除环境：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 运维 > 环境。
3. 选择 Stopped 选项卡。
4. 在要删除的环境旁边选择 Delete environment。
5. 在确认对话框中选择 Delete environment。

出于准备或验证目的访问环境#

您可以定义一个作业，访问环境以进行各种目的，例如验证或准备。这实际上绕过了部署创建，以便您可以更准确地调整您的 CD 工作流程。

为此，请在作业的 environment 部分中添加 action: prepare、action: verify 或 action: access：

yaml
1build:
2  stage: build
3  script:
4    - echo "Building the app"
5  environment:
6    name: staging
7    action: prepare
8    url: https://staging.example.com

这使您可以访问环境范围变量，并可用于保护构建免受未经授权的访问。此外，它有效地避免了 防止过时的部署作业 功能。

如果环境配置为在特定时间段后停止，具有 access 或 prepare 动作的作业将重置计划停止时间。使用环境最近成功部署作业的 environment:auto_stop_in，在重置计划时间时使用。例如，如果最近的部署使用 auto_stop_in: 1 week，并且稍后通过具有 action: access 的作业访问，则环境将重新安排停止时间为访问作业完成后的一周。

要访问环境而不改变计划停止时间，请使用 verify 动作。

环境事件管理#

生产环境可能会意外停止，包括由于您无法控制的原因。例如，外部依赖项、基础设施或人为错误可能导致环境出现重大问题，例如：

• 依赖的云服务停止。
• 第三方库更新，并且与您的应用程序不兼容。
• 有人对您的服务器中的一个脆弱端点进行 DDoS 攻击。
• 操作者错误配置基础设施。
• 在生产应用程序代码中引入了错误。

您可以使用 事件管理 在需要立即关注的关键问题发生时收到警报。

查看环境的最新警报#

如果您 设置了警报集成，环境的警报会显示在环境页面上。显示具有最高严重性的警报，以便您可以识别需要立即关注的环境。

当触发警报的问题得到解决时，它会被移除并且不再在环境页面上显示。

如果警报需要 回滚，您可以从环境页面选择部署选项卡，并选择要回滚到的部署。

自动回滚#

在典型的持续部署工作流程中，CI 流水线在部署到生产之前会测试每个提交。然而，有问题的代码仍然可能进入生产。例如，逻辑正确但效率低下的代码可能通过测试，即使它会导致严重的性能下降。操作员和 SRE 监控系统以尽快发现这些问题。如果发现有问题的部署，他们可以回滚到以前稳定的版本。

极狐GitLab 自动回滚通过在检测到 关键警报 时自动触发回滚来简化此工作流程。 为了让极狐GitLab 选择合适的回滚环境，警报应包含一个 gitlab_environment_name 键和环境名称。 极狐GitLab 选择并重新部署最近一次成功的部署。

极狐GitLab 自动回滚的限制：

• 如果在检测到警报时有部署正在运行，则跳过回滚。
• 回滚只能每三分钟发生一次。如果同时检测到多个警报，则只执行一次回滚。

极狐GitLab 自动回滚默认关闭。要打开它：

1. 在左侧边栏，选择 搜索或转到 并找到您的项目。
2. 选择 设置 > CI/CD。
3. 展开 自动部署回滚。
4. 选中 启用自动回滚 的复选框。
5. 选择 保存变更。

环境权限#

根据您的角色，您可以与公共和私有项目中的环境进行交互。

查看环境#

• 在公共项目中，任何人都可以查看环境列表，包括非成员。
• 在私有项目中，您必须至少拥有 Reporter 角色才能查看环境列表。

创建和更新环境#

• 您必须至少拥有 Developer 角色才能创建新环境或更新现有未保护环境。
• 如果现有环境受到保护且您无权访问它，则无法更新环境。

停止和删除环境#

• 您必须至少拥有 Developer 角色才能停止或删除未保护环境。
• 如果环境受到保护且您无权访问它，则无法停止或删除环境。

在受保护环境中运行部署作业#

如果您可以推送或合并到受保护分支：

• 您必须至少拥有 Reporter 角色。

如果您无法推送到受保护分支：

• 您必须是具有 Reporter 角色的群组的一部分。

请参阅 仅限部署访问受保护环境。

Web 终端（已弃用）#

如果您借助部署服务（例如，Kubernetes 集成）部署到环境，极狐GitLab 可以打开终端会话到您的环境。然后，您可以在不离开网页浏览器的情况下调试问题。

Web 终端是一个基于容器的部署，通常缺少基本工具（如编辑器），并且可以随时停止或重新启动。如果发生这种情况，您将丢失所有更改。将 Web 终端视为调试工具，而不是全面的在线 IDE。

Web 终端：

• 仅对项目管理员和拥有者可用。
• 必须 启用。

在 UI 中，要查看 Web 终端，可以：

• 从 Actions 菜单中选择 Terminal：

  

• 在特定环境的页面上，在右侧选择 Terminal (

  )。

选择按钮以建立终端会话。 它像任何其他终端一样工作。您在部署创建的容器中，因此可以：

• 运行 shell 命令并实时获得响应。
• 检查日志。
• 尝试配置或代码调整。

您可以打开多个终端到同一个环境。它们每个都有自己的 shell 会话，甚至可以使用像 screen 或 tmux 这样的多路复用器。

相关主题#

• Kubernetes 仪表板
• 部署
• 受保护环境
• 环境仪表板
• 部署安全性

故障排除#

action: stop 作业未运行#

在某些情况下，即使已配置 on_stop 作业，环境也不会停止。这发生在具有 action: stop 的作业由于其 stages: 或 needs: 配置未处于可运行状态时。

例如：

• 环境可能在包含失败作业的阶段启动。然后后续阶段的作业不会启动。如果环境的 action: stop 作业也在后续阶段，则无法启动，环境不会被删除。
• 具有 action: stop 的作业可能依赖于尚未完成的作业。

为了确保在需要时 action: stop 总能运行，您可以：

• 将两个作业放在同一个阶段：

  yaml
  1stages:
  2  - build
  3  - test
  4  - deploy
  5
  6...
  7
  8deploy_review:
  9  stage: deploy
  10  environment:
  11    name: review/$CI_COMMIT_REF_SLUG
  12    url: https://$CI_ENVIRONMENT_SLUG.example.com
  13    on_stop: stop_review
  14
  15stop_review:
  16  stage: deploy
  17  environment:
  18    name: review/$CI_COMMIT_REF_SLUG
  19    action: stop
  20  when: manual

• 为 action: stop 作业添加 needs 条目，以便作业可以超出阶段顺序启动：

  yaml
  1stages:
  2  - build
  3  - test
  4  - deploy
  5  - cleanup
  6
  7...
  8
  9deploy_review:
  10  stage: deploy
  11  environment:
  12    name: review/$CI_COMMIT_REF_SLUG
  13    url: https://$CI_ENVIRONMENT_SLUG.example.com
  14    on_stop: stop_review
  15
  16stop_review:
  17  stage: cleanup
  18  needs:
  19    - deploy_review
  20  environment:
  21    name: review/$CI_COMMIT_REF_SLUG
  22    action: stop
  23  when: manual

错误：作业将创建具有无效参数的环境#

如果您的项目配置为 创建动态环境，您可能会在部署作业中遇到此错误，因为动态生成的参数无法用于创建环境：

plaintext
This job could not be executed because it would 创建环境 with an invalid parameter.

---

例如，您的项目具有以下 .gitlab-ci.yml 文件：

yaml
deploy:
  script: echo
  environment: production/$ENVIRONMENT

由于流水线中不存在 $ENVIRONMENT 变量，极狐GitLab 尝试创建一个名为 production/ 的环境，这在环境名称约束中是无效的。

要解决此问题，请使用以下解决方案之一：

• 从部署作业中删除 environment 关键字。极狐GitLab 已经忽略了无效的关键字，因此即使删除关键字后，您的部署流水线仍然保持不变。
• 确保变量存在于流水线中。查看支持的变量限制。

如果在审查应用中出现此错误#

例如，如果您在 .gitlab-ci.yml 文件中有以下内容：

yaml
review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_NAME

当您创建一个新的合并请求，分支名称为 bug-fix! 时，review 作业尝试创建一个名为 review/bug-fix! 的环境。然而，! 是环境中的无效字符，因此部署作业失败，因为它即将运行但没有环境。

要解决此问题，请使用以下解决方案之一：

• 重新创建您的功能分支，去掉无效字符，例如 bug-fix。

• 将 CI_COMMIT_REF_NAME 预定义变量替换为 CI_COMMIT_REF_SLUG，它会去除任何无效字符：

  yaml
  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_SLUG