{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

在处理作业时，您可能会遇到以下问题。

使用 changes: 时作业或流水线意外运行

当使用 rules: changes 或 only: changes 而不使用 合并请求流水线 时，您可能会遇到作业或流水线意外运行的情况。

在没有与合并请求明确关联的分支或标签上，流水线使用上一个 SHA 来计算差异。这个计算等同于 git diff HEAD~，可能导致意外行为，包括：

  • 当推送新分支或新标签到极狐GitLab 时，changes 规则总是评估为真。
  • 当推送新提交时，使用上一个提交作为基准 SHA 来计算更改的文件。

此外，在计划的流水线中，带有 changes 的规则总是评估为真。计划的流水线运行时，所有文件都被认为已更改，因此作业可能总是被添加到使用 changes 的计划流水线中。

CI/CD 变量中的文件路径

使用 CI/CD 变量中的文件路径时要小心。末尾的斜杠在变量定义中看似正确，但在 script:、changes: 或其他关键字中展开时可能无效。例如：

docker_build:
  variables:
    DOCKERFILES_DIR: 'path/to/files/'  # 这个变量不应有一个结尾的 '/' 字符
  script: echo "A docker job"
  rules:
    - changes:
        - $DOCKERFILES_DIR/*

当 DOCKERFILES_DIR 变量在 changes: 部分展开时，完整路径变为 path/to/files//*。双斜杠可能导致意外行为，具体取决于使用的关键字或 runner 的 shell 和操作系统。

You are not allowed to download code from this project. 错误信息

当极狐GitLab 管理员在私有项目中运行受保护的手动作业时，您可能会看到流水线失败。

CI/CD 作业通常在作业开始时克隆项目，并使用运行作业的用户的权限。所有用户，包括管理员，必须是私有项目的直接成员才能克隆该项目的源代码。存在一个议题 来改变这种行为。

要运行受保护的手动作业：

  1. 将管理员添加为私有项目的直接成员（任何角色）
  2. 模拟一个用户，该用户是项目的直接成员。

CI/CD 作业再次运行时不使用更新的配置

流水线的配置仅在创建流水线时获取。每次重新运行作业时，都会使用相同的配置。如果您更新了配置文件，包括使用 include 添加的单独文件，则必须启动新的流水线以使用新配置。

Job may allow multiple pipelines to run for a single action 警告

当您使用 rules 带有 when 子句而没有 if 子句时，可能会运行多个流水线。通常这种情况发生在您向与之关联的开放合并请求的分支推送提交时。

要防止重复流水线，请使用 workflow: rules 或重写您的规则以控制可以运行的流水线。

This GitLab CI configuration is invalid for variable expressions

当使用 CI/CD 变量表达式 时，您可能会收到多个 This GitLab CI configuration is invalid 错误。这些语法错误可能是由引号字符使用不当引起的。

在变量表达式中，字符串应该加引号，而变量不应该加引号。例如：

variables:
  ENVIRONMENT: production

job:
  script: echo
  rules:
    - if: $ENVIRONMENT == "production"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

在这个例子中，两个 if: 子句都是有效的，因为 production 字符串是加引号的，CI/CD 变量是未加引号的。

另一方面，这些 if: 子句都是无效的：

variables:
  ENVIRONMENT: production

job:
  script: echo
  rules:       # 这些规则都导致 YAML 语法错误：
    - if: ${ENVIRONMENT} == "production"
    - if: "$ENVIRONMENT" == "production"
    - if: $ENVIRONMENT == production
    - if: "production" == "production"

在这个例子中：

  • if: ${ENVIRONMENT} == "production" 是无效的，因为 ${ENVIRONMENT} 不是 if: 中 CI/CD 变量的有效格式。
  • if: "$ENVIRONMENT" == "production" 是无效的，因为变量被加了引号。
  • if: $ENVIRONMENT == production 是无效的，因为字符串没有加引号。
  • if: "production" == "production" 是无效的，因为没有要比较的 CI/CD 变量。

get_sources 作业部分因 HTTP/2 问题失败

有时，作业因以下 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 来解决此问题。配置可以添加到：

使用 resource_group 的作业卡住

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: 极狐GitLab私有化部署, 极狐GitLab Dedicated

{{< /details >}}

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

# 通过名称查找资源组
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')

# 确定哪些构建占用了资源
# （我认为截至今天应该是 1）
busy_resources.pluck(:build_id)

# 检查该构建为何占用资源是有益的。
# 它卡住了吗？是否已被系统强制删除？
# 释放繁忙资源
busy_resources.update_all(build_id: nil)

You are not authorized to run this manual job 信息

如果您尝试运行手动作业时收到此消息，并且 Run 按钮被禁用，则可能是因为：