环境

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

通过环境，你可以：

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

查看环境和部署

前提条件：

• 在私有项目中，你必须至少拥有 Reporter 角色。参见 环境权限。

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

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

• 在左侧边栏中，选择 Operate > Environments。 将显示环境列表。

  

• 若要查看某个环境的所有部署，请选择该环境名称（例如 staging）。

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

• 若要查看部署流水线中的所有手动作业，请选择 Run（ ）下拉列表。

  

环境URL

环境URL 在 GitLab 中多个位置显示：

• 合并请求中以链接形式：
• 环境视图中以按钮形式：
• 部署视图中以按钮形式：

若满足以下条件，你可以在合并请求中看到此信息：

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

例如：

从源文件到公开页面

借助 GitLab 路由映射，你可以直接从源文件跳转到审核应用所设置的环境中的公开页面。

环境类型

环境分为静态或动态两种。

静态环境：

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

动态环境：

• 通常在 CI/CD 流水线中创建，仅用于单次部署，之后要么停止要么删除。
• 具有动态名称，通常基于 CI/CD 变量的值。
• 是 审核应用 的功能。

环境的状态取决于其 停止作业 是否运行，共有三种状态：

• available：环境存在。可能有部署。
• stopping：停止作业 已启动。若未定义停止作业，则不适用此状态。
• stopped：停止作业 已运行，或用户手动停止了作业。

创建静态环境

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

在界面中

前提条件：

• 你必须至少拥有开发者角色。

要在界面中创建静态环境：

1. 在左侧边栏，选择 搜索或前往 并找到你的项目。
2. 选择 操作 > 环境。
3. 选择 创建环境。
4. 填写字段。
5. 选择 保存。

在你的 .gitlab-ci.yml 文件中

前提条件：

• 你必须至少拥有开发者角色。

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

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

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

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com

创建动态环境

要创建动态环境，你需使用 CI/CD 变量，这些变量对每个管道都是唯一的。

前提条件：

• 你必须至少拥有开发者角色。

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

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

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

deploy_review_app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: never
    - 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。

review/your-branch-name 环境分配的 URL 在界面中可见。

概览请见 作业完成后设置动态 URL。

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

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

review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # 在脚本中获取环境 URL。
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # 将值添加到 dotenv 文件。
  artifacts:
    reports:
      dotenv: deploy.env                                                       # 向 Rails 上报 dotenv 文件。
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # 将脚本中生成的变量设为 `environment:url`
    on_stop: stop_review

stop_review:
  script:
    - ./teardown-environment
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

注意以下几点：

• stop_review 不生成 dotenv 报告工件，因此无法识别 DYNAMIC_ENVIRONMENT_URL 环境变量。因此你不应在 stop_review 作业中设置 environment:url。
• 如果环境 URL 无效（例如 URL 格式错误），系统不会更新环境 URL。
• 若 stop_review 中运行的脚本仅存在于你的仓库中，因此无法使用 GIT_STRATEGY: none 或 GIT_STRATEGY: empty，则为这些作业配置 合并请求流水线。这能确保即使功能分支被删除，Runner 仍能拉取仓库。更多信息请参见 Runner 的 Ref Specs。

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

环境的部署层级

有时，你可能不想使用行业标准的环境名称，例如 production，而是想使用代码名，例如 customer-portal。虽然从技术上讲可以使用 customer-portal 这样的名称，但它不再表明该环境用于生产环境。这可能影响诸如部署频率等指标的统计方式。

若要表明特定环境用于特定用途，你可以使用层级：

默认情况下，GitLab 会根据环境名称推断层级。你无法通过界面设置环境层级。相反，你可以使用 deployment_tier 关键字 指定层级。

重命名环境

您无法重命名环境。

若需实现与重命名环境相同的效果：

1. 停止现有环境。
2. 删除现有环境。
3. 创建新环境，使用所需名称。

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 变量会在运行时填充分支名：

deploy_review:
  stage: deploy
  script:
    - echo "部署审核应用"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

停止环境

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

当使用 on_stop 动作来停止环境时，若该作业未被 归档，则该作业会运行。

通过 UI 停止环境

在 GitLab UI 中停止环境：

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

默认停止行为

当关联分支被删除或合并时，GitLab 会自动停止环境。即使未定义显式的 on_stop CI/CD 作业，此行为仍会持续。

不过，问题 428625 提议更改此行为，使得仅当定义了显式 on_stop CI/CD 作业时，生产环境和预发布环境才会停止。

您可以通过 Environments 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 就不会在分支被删除后尝试检出代码。

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

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

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

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

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

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

在特定时间后停止环境

你可以设置一个环境在特定时间后自动停止。

在你的 .gitlab-ci.yml 文件中，指定 environment:auto_stop_in 关键字。使用自然语言指定时间段，例如 1 hour and 30 minutes 或 1 day。时间段结束后，GitLab 会自动触发作业来停止该环境。

在下面的示例中：

• 合并请求上的每次提交都会触发 review_app 作业，该作业将最新更改部署到环境中并重置其过期时间。
• 如果环境超过一周未活动，GitLab 会自动触发 stop_review_app 作业来停止该环境。

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      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 设置会被覆盖，环境将保持活跃状态，直到手动停止。

清理过时环境

当你想要停止项目中旧环境时，清理过时环境。

前提条件：

• 你必须至少拥有维护者角色。

若要清理过时环境：

1. 在左侧边栏中，选择 搜索或前往 并找到你的项目。
2. 选择 运营 > 环境。
3. 选择 清理环境。
4. 选择用于确定哪些环境被视为过时的日期。
5. 选择 清理。

自指定日期以来未更新的活跃环境将被停止。受保护的环境会被忽略且不会被停止。

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

你可以通过在环境的部署作业中使用 on_stop 动作 来定义该环境的停止作业。

当环境停止时，最新完成的流水线中已完成部署的停止作业会被运行。若部署或流水线的状态为成功、取消或失败，则视为已完成。

前提条件：

• 部署和停止作业必须具有相同的规则或仅/排除配置。
• 停止作业必须定义以下关键字：
  • when，可在以下位置定义：
    • 作业级别。
    • 在 rules 子句中。如果你使用 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 不会尝试在分支删除后检出代码。

review_app:
  stage: deploy
  script: make deploy-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

为环境配置多个停止操作

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

当环境停止时，仅来自成功部署作业的匹配 on_stop 操作会并行运行，无特定顺序。

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

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

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

deploy-to-cloud-a:
  script: echo "Deploy to cloud a"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "Deploy to cloud b"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "Delete the resources in cloud a"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "Delete the resources in cloud b"
  environment:
    name: test
    action: stop
  when: manual

停止环境而不运行 on_stop 操作

有时你可能希望停止环境而不运行已定义的 on_stop 操作。例如，你想在不使用 计算配额 的情况下删除许多环境。

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

删除环境

当你想要删除某个环境及其所有部署时，可将其删除。

前提条件：

• 你必须至少拥有开发者角色。
• 你必须在删除该环境前先停止它。

要删除一个环境：

1. 在左侧边栏中，选择搜索或跳转并找到你的项目。
2. 选择运维 > 环境。
3. 选择已停止标签页。
4. 在你要删除的环境旁，选择删除环境。
5. 在确认对话框中，选择删除环境。

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

你可以定义一个作业，用于以各种目的（如验证或准备）访问环境。这会有效绕过部署创建过程，让你能更精确地调整持续交付（CD）工作流。

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

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com

这会让你能够访问环境作用域内的变量，并可用来保护构建免受未授权访问。此外，它能有效避免 防止过时部署作业 功能。

如果一个环境被配置为在特定时间后自动停止，带有 access 或 prepare 动作的作业将会重置计划的停止时间。重置计划时间时会使用环境中最近一次成功部署作业的 environment:auto_stop_in。例如，如果最近的部署使用了 auto_stop_in: 1 周，之后被带有 action: access 的作业访问，那么该环境将被重新安排在一周后停止（从访问作业完成时算起）。

若要在不更改计划停止时间的情况下访问环境，请使用 verify 动作。

环境事件管理

生产环境可能会意外宕机，包括因超出你控制范围的原因。例如，外部依赖项问题、基础设施问题或人为错误都可能导致环境出现重大问题。例如：

• 依赖的云服务宕机。
• 第三方库被更新且与你的应用不兼容。
• 有人对你的服务器中易受攻击的端点发起 DDoS 攻击。
• 运维人员误配置了基础设施。
• 生产应用代码中引入了一个缺陷。

你可以使用 事件管理 在出现需要立即关注的严重问题时获得警报。

查看环境的最新警报

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

当触发警报的问题得到解决后，该警报会被移除，不再出现在环境页面上。

如果警报需要进行回滚，你可以从环境页面的部署标签页中选择要回滚到的部署。

自动回滚

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

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

GitLab 自动回滚的限制：

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

GitLab 自动回滚默认关闭。要开启它：

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

环境权限

根据您的角色，您可以在公开项目和私有项目中与 environments 交互。

查看环境

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

创建和更新环境

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

停止和删除环境

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

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

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

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

如果您不能推送到受保护的分支：

• 您必须是具有 Reporter 角色的组的成员。

参见 仅部署访问受保护的环境。

Web 终端（已弃用）

如果您使用部署服务（例如Kubernetes 集成）部署到环境中，GitLab 可以打开一个终端会话到您的环境中。您可以无需离开浏览器即可调试问题。

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

Web 终端：

• 仅对项目的维护者和所有者可用。
• 必须启用。

在 UI 中，要查看 Web 终端，可以通过以下方式：

• 从 操作 菜单中选择 终端：

  

• 在特定环境的页面上，右侧选择 终端（ ）。

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

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

您可以打开多个指向同一环境的终端。它们各自拥有独立的 shell 会话，甚至可以使用 screen 或 tmux 这类多路复用器。

相关主题

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

故障排除

带有 action: stop 的作业无法运行

在某些情况下，尽管配置了 on_stop 作业，环境仍不会停止。这是因为带有 action: stop 的作业由于 stages: 或 needs: 配置而处于不可运行状态。

例如：

• 环境可能在某个阶段启动，该阶段中也有一个失败的作业。随后，后续阶段的作业不会启动。如果环境的 action: stop 作业也在后续阶段，它就无法启动，环境也不会被删除。
• 带有 action: stop 的作业可能依赖于尚未完成的作业。

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

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

  stages:
    - build
    - test
    - deploy
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual

• 为 action: stop 作业添加一个 needs 条目，使作业能脱离阶段顺序启动：

  stages:
    - build
    - test
    - deploy
    - cleanup
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: cleanup
    needs:
      - deploy_review
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual

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

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

此作业无法执行，因为它会创建具有无效参数的环境。

例如，你的项目有以下 .gitlab-ci.yml：

deploy:
  script: echo
  environment: production/$ENVIRONMENT

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

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

• 从部署作业中移除 environment 关键字。GitLab 已经忽略了无效的关键字，因此即使移除了关键字，你的部署管道也会保持完整。
• 确保管道中存在该变量。查看 受支持变量的限制。

如果你在审核应用（review apps）上遇到此错误

例如，如果你的 .gitlab-ci.yml 中有以下内容：

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，它会去除任何无效字符：

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