引言
在编写 GitLab CI/CD 流水线配置（.gitlab-ci.yml）时，我们常常会遇到一个棘手的问题：重复。多个作业（Job）可能共享相同的配置，比如都在同一个 stage，使用同样的 tags，或者执行一段相同的准备脚本。当需要修改这些通用配置时，我们必须逐一修改每个作业，这不仅繁琐，而且极易出错。为了遵循软件工程中最重要的原则之一------"不要重复自己"（DRY, Don't Repeat Yourself），GitLab CI 提供了一个优雅的解决方案：隐藏作业 。它们就像是流水线配置中的"幕后英雄"，默默地为我们提供可复用的模板，让整个CI/CD配置变得简洁、清晰且易于维护。
- 什么是隐藏作业？
隐藏作业的定义非常简单：任何以点（.）开头的作业都被视为隐藏作业。
yaml
.my_hidden_job:
script:
- echo "This job will NOT run in the pipeline."
tags:
- my-runner它的核心特性是：GitLab CI 的解析器会识别这个作业，但不会将它添加到任何流水线的实际执行序列中 。换句话说，我们永远不会在 GitLab 的流水线视图中看到一个名为 .my_hidden_job 的作业在运行。
我们可以把它理解为一个"配置模板"或"蓝图"。它本身不是一座房子，但它详细描绘了建造房子某一特定部分（例如，地基、墙体）所需的所有规格和步骤。
- 为什么我们需要隐藏作业？
隐藏作业的主要目的就是复用。通过将通用的配置抽离到隐藏作业中，我们可以获得三大核心优势：
-
实现配置的极致复用 ：这是最直接的好处。无论是变量、执行脚本、环境定义、Runner标签（
tags）、缓存策略（cache）还是制品（artifacts）规则，任何可以在作业中定义的键值对，都可以放入隐藏作业中，供其他作业继承。 -
提升可维护性：想象一下，我们有10个作业都需要在一个特定的Docker镜像中运行。如果将来需要升级这个镜像版本，我们只需要修改定义该镜像的那个隐藏作业即可，所有继承它的10个作业将自动更新。这大大降低了维护成本和因疏忽导致配置不一致的风险。
-
构建清晰的配置结构 ：隐藏作业可以作为逻辑分组的单元。我们可以创建
.base_template、.docker_build_template、.deploy_to_aws_template等具有明确语义的模板。这使得.gitlab-ci.yml文件本身就具备了自解释性，新加入的团队成员可以更快地理解整个CI/CD的结构和逻辑。
- 如何使用隐藏作业？核心关键字 extends
隐藏作业本身不会运行，那么如何让其他作业使用它呢？答案是使用 GitLab CI 提供的 extends 关键字。extends 允许一个常规作业"继承"一个或多个隐藏作业的配置。
基础用法：单继承
假设我们有两个作业，都需要在 build 阶段执行，并使用相同的准备脚本。
yaml
# 1. 定义一个隐藏作业作为模板
.base_build_template:
stage: build
tags:
- docker-builder
before_script:
- echo "Logging into private registry..."
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
# 2. 让常规作业通过 extends 继承模板
build_project_a:
extends: .base_build_template
script:
- echo "Building Project A..."
- docker build -t project-a .
build_project_b:
extends: .base_build_template
script:
- echo "Building Project B..."
- docker build -t project-b .在这个例子中，build_project_a 和 build_project_b 都自动获得了 .base_build_template 中定义的所有配置（stage, tags, before_script）。同时，它们也定义了自己的 script，这会与继承来的配置进行合并。
配置合并与覆盖规则
当一个作业继承模板时，GitLab 会执行一个深度合并（deep merge）策略：
- 对于字典/哈希（如
variables）：会进行合并。 - 对于数组/序列（如
script,tags） ：子作业（继承者）的定义会完全覆盖父模板的定义。 - 对于其他值（如
stage,image）：子作业的定义会覆盖父模板的定义。
进阶用法：多重继承
extends 甚至可以接受一个隐藏作业的列表，实现多重继承。这允许我们像搭积木一样组合不同的配置片段。
yaml
# 模板1: 定义Runner环境
.on_production_runner:
tags:
- production
# 模板2: 定义部署脚本的通用逻辑
.base_deploy_script:
before_script:
- ./prepare_deployment.sh
script:
- ./execute_deployment.sh
after_script:
- ./cleanup.sh
# 组合使用的常规作业
deploy_to_production:
stage: deploy
extends:
- .on_production_runner
- .base_deploy_script
variables:
DEPLOY_TARGET: "production-server-1"在多重继承中，合并顺序是从左到右。如果多个模板定义了相同的键，最右边的模板会"获胜"。最后，常规作业自身的定义优先级最高，会覆盖所有继承来的配置。
- 可视化继承关系
为了更清晰地展示这种继承和组合关系，我们可以使用 UML 进行建模。这就像是软件设计中的类继承图。
这张图清晰地展示了 build_app 作业同时继承了 .base_template 和 .docker_template，而 test_app 只继承了 .base_template。
结论
GitLab CI 的隐藏作业是提升 .gitlab-ci.yml 配置文件质量的"银弹"。通过与 extends 关键字的完美配合，它将配置复用、模块化和可维护性提升到了一个新的高度。它不仅仅是一个语法特性，更是一种编写CI/CD配置的设计模式。当我们下一次发现自己在复制粘贴CI/CD配置时，请停下来想一想：是否可以创建一个隐藏作业来将这些重复的逻辑抽象出来？养成使用隐藏作业的习惯，我们将能够构建出更专业、更健壮、更易于管理的自动化流水线。