• 查看流水线中的作业
  • 查看项目中的所有作业
• 查看作业失败的原因
• 作业名称限制
• 流水线中分组作业
• 隐藏作业
• 控制默认关键字和全局变量的继承
• 运行手动作业时指定变量
• 延迟作业
• 部署作业
• 故障排查
  • 由于 HTTP/2 问题导致 get_sources 作业部分失败
  • 使用 resource_group 的作业会卡住 （BASIC ALL）

作业

CI/CD 作业是极狐GitLab CI/CD 流水线的最基本元素。作业在 .gitlab-ci.yml 文件中配置为命令列表，以执行诸如构建、测试或部署代码之类的任务。

工作是：

• 定义在顶级的 YAML 文件中。
• 必需要一个唯一的名称。
• 要么有一个定义运行命令的 script 部分，要么有一个触发下游流水线的 trigger 部分。
• 在 runner 中执行，例如在 Docker 容器中。
• 独立运行。
• 有一个完整的执行日志，称为 作业日志。

例如：

my-ruby-job:
  script:
    - bundle install
    - bundle exec my_ruby_command

my-shell-script-job:
  script:
    - my_shell_script.sh

作业可以用 YAML 关键字定义，这些关键字定义了作业执行的所有方面，包括：

• 控制哪些流水线作业应该被执行。
• 将作业“归类”到 stage中。Stage 按顺序运行，但同一 stage 中的所有作业可以并行运行。
• 使用 缓存来加速作业执行。
• 将文件保存为 artifacts 以便被其他作业使用，包括在部署中使用。

查看流水线中的作业

当您访问流水线时，您可以看到该流水线的相关作业。

流水线中的作业顺序取决于流水线图的类型。

• 对于完整的流水线图，作业以名称排序。

• 对于流水线最小图，作业通过状态、然后通过名称进行排序。作业的状态顺序为： The job status order is:

  1. 失败的（failed）
  2. 告警（warning）
  3. 等待（pending）
  4. 运行（running）
  5. 手动（manual）
  6. 定时（scheduled）
  7. 取消（canceled）
  8. 成功（success）
  9. 调整（skipped）
  10. 创建（created）

选择单个作业并展示他的作业日志，并允许您：

• 取消作业。
• 如果失败，重试作业。
• 如果通过，再次运行作业。
• 清除作业日志。

查看项目中的所有作业

要查看项目中运行的作业的完整列表：

1. 在左侧边栏中，选择 搜索或转到 并找到您的项目。
2. 在左侧边栏中，选择 构建 > 作业。

您可以通过作业状态和作业名称来过滤列表。

查看作业失败的原因

当流水线发生故障或被允许发生故障时，您可以在以下几个地方找到原因：

• 在流水线图中的流水线详细信息视图中。
• 在流水线部件，在合并请求和提交页面中。
• 在作业视图，在作业的全局视图和详细视图中。

在每个地方，如果您将鼠标悬停在失败的作业上，您可以看到它失败的原因。

您还可以在作业详细信息页面上查看失败的原因。

作业名称限制

您不能将这些关键字用作作业名称：

• image
• services
• stages
• before_script
• after_script
• variables
• cache
• include
• 为 deploy stage 配置的 pages:deploy

此外，这些名称在引用时有效，但不建议使用，因为它们可能会使流水线配置变得不清楚：

• "true":
• "false":
• "nil":

作业名称不得超过 255 个字符。

为您的作业使用唯一名称。如果多个作业具有相同的名称，则只会将一个添加到流水线中，并且很难预测会选择哪一个。

流水线中分组作业

如果您有许多类似的作业，您的流水线图会变得很长且难以阅读。

您可以自动将相似的作业组合在一起。如果作业名称以某种方式格式化，它们将在常规流水线图（而不是迷你图）中折叠成一个组。

如果您没有在其中看到重试或取消按钮，您可以识别流水线何时对作业进行了分组。将鼠标悬停在它们上会显示分组作业的数量，单击可以展开它们。

要创建一组作业，请在 CI/CD 流水线配置文件中，将每个作业名称用数字和以下之一分隔：

• 斜线（/），例如 slash-test 1/3、slash-test 2/3、slash-test 3/3。
• 冒号 (:)，例如 colon-test 1:3、colon-test 2:3、colon-test 3:3。
• 一个空格，例如 space-test 0 3、space-test 1 3、space-test 2 3。

您可以互换使用这些符号。

在下面的示例中，这三个作业位于名为 build ruby 的组中：

build ruby 1/3:
  stage: build
  script:
    - echo "ruby1"

build ruby 2/3:
  stage: build
  script:
    - echo "ruby2"

build ruby 3/3:
  stage: build
  script:
    - echo "ruby3"

流水线图显示了一个名为 build ruby 的组，其中包含三个作业。

通过从左到右比较数字来对作业进行排序。您通常希望第一个数字是索引，第二个数字是总数。

此正则表达式 评估作业名称：([\b\s:] +((\[.*\])|(\d+[\s:\/\\]+\d+)))+\s*\z。 一个或多个: [...]、X Y、X/Y 或X\Y 序列仅从作业名称的结尾中删除。在作业名称的开头或中间找到的匹配子字符串不会被删除。

在 13.8 及更早版本中，正则表达式为 \d+[\s:\/\\]+\d+\s*。功能标志在 13.11 版本中删除。

隐藏作业

要暂时禁用作业而不将其从配置文件中删除：

• 注释掉作业的配置：

  # hidden_job:
  #   script:
  #     - run test
  

• 以点（.）开头的作业名称，它不会被 GitLab CI/CD 处理：

  .hidden_job:
    script:
      - run test
  

您可以使用以 . 开头的隐藏作业作为可重用配置的模板：

• extends 关键字。
• YAML 锚点。

控制默认关键字和全局变量的继承

您可以控制以下事项的继承：

• 默认关键字 和 inherit:default。
• 全局变量 和 inherit:variables。

例如：

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
  WEBHOOK_URL: https://my-webhook.example.com

rubocop:
  inherit:
    default: false
    variables: false
  script: bundle exec rubocop

rspec:
  inherit:
    default: [image]
    variables: [WEBHOOK_URL]
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma

在这个例子中：

• rubocop：
  • 继承：没有。
• rspec：
  • 继承：默认的 image 和 WEBHOOK_URL 变量。
  • 不 继承：默认的 before_script 和DOMAIN 变量。
• capybara：
  • 继承：默认的 before_script 和image。
  • 不 继承：DOMAIN 和WEBHOOK_URL 变量。
• karma：
  • 继承：默认的 image 和before_script，以及 DOMAIN 变量。
  • 不 继承：WEBHOOK_URL 变量。

运行手动作业时指定变量

运行手动作业时，您可以提供额外的作业特定变量。

您可以从要使用其他变量运行的手动作业的作业页面执行此操作。要访问此页面，请单击流水线视图中手动作业的名称，而不是运行 () 按钮。

当您想要更改使用自定义 CI/CD 变量的作业的执行时，这很有用。 在此处添加变量名称（键）和值以覆盖在 UI 或 .gitlab-ci.yml 中定义的值，用于单次运行手动作业。

延迟作业

当您不想立即运行作业时，可以使用 when:delayed 关键字，在一定时期内来延迟作业的执行。

这对于逐步推出新代码的定时增量推出特别有用。

例如，如果您开始推出新代码并且：

• 用户没有遇到麻烦，极狐GitLab 可以自动完成从 0% 到 100% 的部署。
• 用户在使用新代码时遇到问题，您可以通过取消流水线和回滚，停止定时增量部署，回到最后的稳定版。

部署作业

部署作业是一种特定类型的 CI 作业，因为它们将代码部署到环境。部署作业是使用 environment 关键字和 start 环境 action 的任何作业。 部署作业不需要处于 deploy 阶段。以下 deploy me 作业是部署作业的一个示例。action: start 是默认行为，是为了示例而定义的，但您可以省略它：

deploy me:
  script:
    - deploy-to-cats.sh
  environment:
    name: production
    url: https://cats.example.com
    action: start

部署作业的行为可以使用诸如阻止过期的部署作业和确保只有一个部署作业同时运行之类的部署安全设置来控制。

故障排查

由于 HTTP/2 问题导致 get_sources 作业部分失败

有时候，作业失败，出现以下 cURL 错误：

++ git -c 'http.userAgent=gitlab-runner <version>' fetch origin +refs/pipelines/<id>:refs/pipelines/<id> ...
error: RPC failed; curl 16 HTTP/2 send again with decreased length
fatal: ...

您可以通过配置 Git 和 libcurl 来使用 HTTP/1.1 来解决此问题。配置可以被添加到：

• 作业的 pre_get_sources_script 中：

  job_name:
    hooks:
      pre_get_sources_script:
        - git config --global http.version "HTTP/1.1"
  

• runner 的 config.toml中，并使用 Git 配置环境变量：

  [[runners]]
  ...
  environment = [
    "GIT_CONFIG_COUNT=1",
    "GIT_CONFIG_KEY_0=http.version",
    "GIT_CONFIG_VALUE_0=HTTP/1.1"
  ]
  

使用 resource_group 的作业会卡住 （BASIC ALL）

如果使用 resource_group 的作业被卡住，极狐GitLab 管理员可以尝试从 rails 控制台运行以下命令：

# find resource group by name
resource_group = Project.find_by_full_path('...').resource_groups.find_by(key: 'the-group-name')
busy_resources = resource_group.resources.where('build_id IS NOT NULL')

# identify which builds are occupying the resource
# (I think it should be 1 as of today)
busy_resources.pluck(:build_id)

# it's good to check why this build is holding the resource.
# Is it stuck? Has it been forcefully dropped by the system?
# free up busy resources
busy_resources.update_all(build_id: nil)