Gitlab CI中如何设置作业启动超时

问题描述

在使用Gitlab CI时遇到了一个问题。他的流水线包含了非常长的作业，这些作业通过编译一组软件包来构建Docker镜像；每个作业需要大约3个小时的时间在他的Runner上运行。他设置了CI只能同时运行一个作业，以减少磁盘I/O开销。但是这样做导致很多作业失败，原因是它们遇到了作业启动超时，超时时间似乎是1小时，出现以下错误信息：

There has been a timeout failure or the job got stuck. Check your timeout limits or try again

用户找不到如何增加作业启动超时的方法，因为他找到的所有文档都是关于作业持续时间超时的。他需要帮助解决这个问题。他使用的是GitLab CE 12.8.1和Gitlab Runner 11.5.1。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

在GitLab CI中，有三种类型的超时设置：项目超时、Runner超时和作业超时。

项目超时

根据GitLab文档：

超时定义了作业能够运行的最长时间（以分钟为单位）。这可以在项目的“设置 > CI/CD > 通用流水线设置”中进行配置。默认值为60分钟。如果要对作业的运行时间设置硬限制，可以减少时间限制；否则，可以增加时间限制。无论如何，如果作业超过阈值，它将被标记为失败。

Runner超时

根据GitLab文档：

对于每个Runner，您可以指定一个最大作业超时时间。

Runner超时设置在Runner的编辑页面中定义。

作业超时

GitLab CI/CD Pipeline配置参考文档中提到：

作业的超时允许您为特定的作业配置超时时间。例如：

build:
  script: build.sh
  timeout: 3 hours 30 minutes
test:
  script: rspec
  timeout: 3h 30m

不同类型超时的优先级

作业级别的超时时间可以超过项目级别的超时时间，但不能超过Runner特定的超时时间。
如果Runner超时时间小于项目定义的超时时间，则以Runner超时时间为准。

以下是超时指令优先级的示例：

name: Example 1 - Runner timeout bigger than project timeout
  project_timeout: 2h
  runner_timeout: 24h
  job_timeout: 4h
  resulting_timeout: 4h
name: Example 2 - Runner timeout not configured
  project_timeout: 2h
  job_timeout: 4h
  resulting_timeout: 4h
name: Example 3 - Runner AND job timeout are not configured
  project_timeout: 24h
  resulting_timeout: 24h
name: Example 4 - Runner timeout smaller than project timeout
  project_timeout: 2h
  runner_timeout: 30m
  resulting_timeout: 30m
name: Example 5 - Runner timeout smaller than Project timeout, Job timeout is bigger than Runner timeout
  project_timeout: 2h
  runner_timeout: 30m
  job_timeout: 1h
  resulting_timeout: 30m

方案2

使用脚本或工具来管理Runner的可用性和作业的启动顺序可能会增加复杂性，并且需要确保Runner的可用性和作业的依赖关系正确设置。

另一种方法是编写脚本或使用工具来控制Runner的可用性和作业的启动顺序。您可以使用gitlab-runner命令来手动控制Runner的启动顺序，或者使用一些第三方工具来管理Runner的可用性和作业的依赖关系。

希望以上解决方案能够帮助您解决问题。如果您有任何进一步的问题，请随时提问。