查看环境和部署
- 环境 URL
  - Go from source files to public pages
环境类型
环境部署级别
- 重命名环境
CI/CD 变量
- 限制 CI/CD 变量的环境范围
搜索环境
相似环境分组
环境权限
故障排查
- 带有 action:stop 的作业没有运行
- Error: 作业会创建具有无效参数的环境
  - 如果您在 Review Apps 上收到此错误

环境

环境可以将极狐GitLab 连接到您的基础设施。环境：

可以监控和部署到其目标基础设施。
有它自己的变量。
可以是长期存在的或短暂的，具体取决于其使用情况。

此外，可以控制对环境的访问。

查看环境和部署

先决条件：

在私有项目中，您必须至少拥有报告者角色。查看环境权限。

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

在项目的概览页面上，如果至少有一个环境可用（未停止）。
在左侧边栏中，选择 运维 > 环境，显示环境。
要查看环境的部署列表，请选择环境名称，例如 staging。

部署仅在部署作业创建之后才会显示在此列表中。

环境 URL

在极狐GitLab 15.2 中，环境 URL 可以是任意 URL，使用名为 soft_validation_on_external_url 的功能标志。默认禁用。

该功能在极狐GitLab 15.3 中正式可用。功能标志 soft_validation_on_external_url 被移除。

环境 URL会展示在极狐GitLab 的几个地方：

在合并请求中，以链接形式：
在环境查看中，以按钮形式：
在部署中，以按钮形式：

你可以在合并请求中看到此信息，如果：

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

比如：

Go from source files to public pages

有了极狐GitLab 路由地图，您可以直接从源文件转到为 Review Apps 设置的环境中的公共页面。

环境类型

环境是静态的或动态的：

静态环境 - 通常由连续的部署重用。 - 具有静态名称 - 例如，staging 或 production。 - 手动创建或作为 CI/CD 流水线的一部分创建。动态环境 - 通常在 CI/CD 流水线中创建并仅由单个部署使用，然后停止或删除。 - 具有动态名称，通常基于 CI/CD 变量的值。 - 作为 review apps 的一项功能。

环境至少有三个状态中的一个，取决于其停止作业是否已运行：

available：环境已存在。可能是一个部署。
stopping：on stop job 已经启动。当未定义任何 “停止时作业” 时，此状态不适用。
stopped：或 on stop job 已经在运行，或手动停止作业。 or a user manually stopped the job.

创建静态环境

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

UI 界面

先决条件：

您必须至少具有开发者角色。

要在 UI 中创建静态环境：

在左侧边栏中，选择 搜索或转到 并找到您的项目。
在左侧边栏中，选择 运维 > 环境。
选择 新建环境。
配置各个字段。
选择保存。

`.gitlab-ci.yml` 文件

先决条件：

您必须至少具有开发者角色。

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

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

环境名称中不能使用某些字符。有关 environment 关键字的更多信息，请参阅 .gitlab-ci.yml 关键字参考。

例如，要创建一个名为 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 文件中：

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

环境名称中不能使用某些字符。有关 environment 关键字的更多信息，请参阅 .gitlab-ci.yml 关键字参考。

在以下示例中，每次运行 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
  only:
    - branches
  except:
    - main

设置动态环境 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 在 UI 中可见。

在下面的示例中，review app 为每一个合并请求创建了一个新环境：

每次推送都会触发 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)                                 # In script, get the environment URL.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # Report back dotenv file to rails.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `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，那么请为这些作业配置合并请求流水线。这可以确保即使在功能分支被删除后，运行器仍能获取仓库内容。有关更多信息，请参阅运行器的引用规范。

对 Windows runner，你应该使用 PowerShell Add-Content 命令来写入 .env 文件。

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

环境部署级别

有时，您可能不想使用行业标准环境名称（如 production），而是希望使用代码名称（如 customer-portal）。虽然没有技术上的理由不使用 “customer-portal 这样的名称，但该名称不再表明该环境用于生产。

要指示特定环境用于特定用途，您可以使用 tier：

环境 tier	环境名称示例
`production`	Production, Live
`staging`	Staging, Model, Demo
`testing`	Test, QC
`development`	Dev, Review apps, Trunk
`other`

默认情况下，系统假定一个基于环境名称的 tier。相反，您可以使用 deployment_tier 关键字来指定 tier。

重命名环境

用 API 重命名环境弃用于极狐GitLab 15.9。

用 API 重命名环境移除于极狐GitLab 16.0。

你无法重命名环境。

要想获得与重命名环境相同的结果：

停止既有环境。
删除既有环境
用期望的名称创建新的环境。

CI/CD 变量

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

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

通过定义 CI/CD 变量可使用的环境，来限制该变量的环境作用范围。默认的环境范围为 * 范围，因此任何作业都可以访问变量。

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

你还可以使用通用匹配（*）来选择特定环境组，例如所有具有 review/* 的 review apps。

例如，如果有四个环境：

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

每个环境都可以与以下 environment spec 匹配：

↓ 范围 / 环境 →	`production`	`staging`	`review/feature-1`	`review/feature-2`
*	匹配	匹配	匹配	匹配
production	匹配
staging		匹配
review/*			匹配	匹配
review/feature-1			匹配

你不应该使用具有 rules 或 include的环境变量。在极狐GitLab 创建流水线并验证流水线配置时，这些变量可能未被定义。

搜索环境

引入于极狐GitLab 15.5。

在文件夹中搜索环境引入于极狐GitLab 15.7，使用名为 enable_environments_search_within_folder 的功能标志。默认启用。

此功能在极狐GitLab 17.4 中正式可用。功能标志 enable_environments_search_within_folder 被移除。

通过名称来搜索环境： 1. 在左侧导航栏，选择 搜索或前往 并找到你的项目。 1. 选择 运维 > 环境。 1. 在搜索栏中，输入搜索术语。 - 搜索术语的 长度应该为 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 "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

停止环境

停止环境意味着无法在目标服务器上访问其部署。您必须先停止环境，然后才能将其删除。

通过使用 UI 来停止环境

要从环境视图触发一个 on_stop 操作并停止一个环境，则停止和部署作业必须位于相同的 resource_group 中。

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

在左侧导航栏，选择 搜索或前往 并找到你的项目。
选择 运维 > 环境。
在你想要停止的环境旁边，选择停止。
在确认对话框中，选择 停止环境。

删除分支时停止环境

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

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

两个作业必须具有相同的 rules 或 only/except 配置。否则，stop_review 作业可能不会包含在具有 deploy_review 作业的所有流水线中，并且您无法触发 action: stop 来自动停止环境。
如果比启动环境的作业晚。带有 action: stop 的作业可能不会运行。
如果您不能使用合并请求流水线，请将 GIT_STRATEGY 在 stop_review 作业中设置为 none。然后 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 作业来清理和停止环境。

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

在特定时间段后停止环境

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

由于资源限制，用于停止环境的后台 worker 每小时仅运行一次。这意味着环境可能不会在指定的确切时间段后停止，而是在后台 worker 检测到过期环境时停止。

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

在以下示例：

合并请求的每次提交都会触发一个 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

查看环境的预定停止日期和时间

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

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

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

到期日期和时间显示在左上角，环境名称旁边。

覆盖环境的预定停止日期和时间

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

要覆盖环境的到期时间：

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

要在 .gitlab-ci.yml 文件中覆盖环境的过期信息：

打开项目的 .gitlab-ci.yml 文件。
更新相应的部署作业的 auto_stop_in，将其设置为 auto_stop_in: never。

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

清理陈旧环境

引入于极狐GitLab 15.8，使用名为 stop_stale_environments 的环境变量。默认禁用。

在极狐GitLab 15.10 中正式可用。功能标志 stop_stale_environments 被移除。

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

先决条件：

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

要清理陈旧环境：

在左侧导航栏，选择 搜索或前往 并找到你的项目。
选择 运维 > 环境。
选择 清理环境。
选择用于确定哪些环境被认为是陈旧的日期。
选择清理。

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

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

功能标志 environment_stop_actions_include_all_finished_deployments 引入于极狐GitLab 16.9。默认禁用。

功能标志 environment_stop_actions_include_all_finished_deployments 在极狐GitLab 17.0 中被移除。

你可以在环境的部署作业中定义一个停止作业，该作业在环境停止时运行。

在最新完成的流水线中，完成部署中的停止作业会被运行。如果作业是成功的、被取消的或失败的状态，则部署或流水线是 完成的。

先决条件：

两个作业必须具有相同的规则或 only/except 配置。
stop_review_app 作业必须定义以下关键字：
- when，定义于：
  - 工作级别。
  - 在规则子句中。如果您使用 rules: 和 when: manual，您还应该设置 allow_failure: true，这样即使作业没有运行，流水线也可以完成。
- environment:name
- environment:action

在以下示例中：

review_app 作业在第一个作业完成后调用 stop_review_app 作业。
stop_review_app 是根据 when 下定义的内容触发的。在这种情况下，它被设置为 manual，因此需要来自 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

环境的多个停止操作

一般可用于 15.0 版本。功能标志 environment_multiple_stop_actions 已删除。

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

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

环境的所有 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 操作的情况下停止环境。例如，您想在不使用 CI/CD 分钟数的情况下删除许多环境。

要在不运行定义的 on_stop 操作的情况下停止环境，请使用参数 force=true 执行停止环境 API。

删除环境

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

先决条件：

您必须至少具有开发者角色。
您必须先停止环境才能将其删除。

要删除环境：

在左侧边栏中，选择 搜索或转到 并找到您的项目。
在左侧边栏中，选择 运维 > 环境。
选择 已停止 选项卡。
在要删除的环境旁边，选择 删除环境。
在确认对话框中，选择 删除环境。

访问环境用于准备或验证的环境

您可以定义访问环境用于各种目的的作业，例如验证或准备，可以有效地绕过部署创建，以便您可以更准确地调整 CD 工作流程。

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

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

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

环境事件管理

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

依赖的云服务出现故障。
更新了第三方库，它与您的应用程序不兼容。
有人对您服务器中的易受攻击的端点进行 DDoS 攻击。
运营商错误配置基础设施。
在生产应用程序代码中引入了一个错误。

您可以使用事件管理在出现需要立即关注的关键问题时获取警报。

查看环境的最新警报

如果您为 Prometheus 指标设置警报，环境警报将显示在环境页面上。显示具有最高严重性的警报，因此您可以确定哪些环境需要立即关注。

当触发警报的问题得到解决后，它会被删除并且在环境页面上不再可见。

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

自动回滚

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

系统自动回滚通过在检测到严重警报时，自动触发回滚来简化此工作流程。系统选择并重新部署最近成功的部署。

系统自动回滚的限制：

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

系统自动回滚默认是关闭的。要开启：

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

环境权限

取决于你的角色，你可以在公开和私有项目中与环境交互。

查看环境

在公共项目中，任何人都可以查看环境列表，包括非成员。
在私有项目中，你必须至少具有报告者角色来查看环境列表。

创建和更新环境

你必须至少具有开发者角色来创建新的环境或更新既有的非受保护环境。
如果既有的环境是受保护的并且你无法访问它，那么你就不能更新环境。

停止和删除环境

你必须至少具有开发者角色来停止或删除非受保护环境。
如果环境是非受保护的并且你无法访问它，那么你就无法停止或删除环境。

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

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

你必须至少具有报告者角色。

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

你必须是具有报告者角色群组的一部分。

查看对受保护环境的仅部署访问权限。

故障排查

带有 `action:stop` 的作业没有运行

在有些情况下，尽管配置了 on_stop，但是环境并不会停止。当 action: stop 作业由于其 stages: 或 needs: 配置而无法运行时，就会发生这种情况。

比如：

环境可能会在已经有作业失败的 stage 中启动。然后，随后 stage 中的作业就不会开始。如果随后 stage 中的环境作业具有 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

Error: 作业会创建具有无效参数的环境

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

This job could not be executed because it would create an environment with an invalid parameter.

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

deploy:
  script: echo
  environment: production/$ENVIRONMENT

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

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

从部署作业中删除 environment 关键字。系统已经忽略了 invalid 关键字，因此即使在删除关键字后，您的部署流水线也保持完整。
确保变量存在于流水线中。请注意，支持的变量有限制。

如果您在 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
```

环境

查看环境和部署

环境 URL

Go from source files to public pages

环境类型

创建静态环境

UI 界面

.gitlab-ci.yml 文件

创建动态环境

设置动态环境 URL

环境部署级别

重命名环境

CI/CD 变量

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

搜索环境

相似环境分组

停止环境

通过使用 UI 来停止环境

删除分支时停止环境

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

在特定时间段后停止环境

查看环境的预定停止日期和时间

覆盖环境的预定停止日期和时间

清理陈旧环境

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

环境的多个停止操作

在不运行 on_stop 操作的情况下停止环境

删除环境

访问环境用于准备或验证的环境

环境事件管理

查看环境的最新警报

自动回滚

环境权限

查看环境

创建和更新环境

停止和删除环境

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

故障排查

带有 action:stop 的作业没有运行

Error: 作业会创建具有无效参数的环境

如果您在 Review Apps 上收到此错误

`.gitlab-ci.yml` 文件

在不运行 `on_stop` 操作的情况下停止环境

带有 `action:stop` 的作业没有运行