GitLab CI/CD 实例配置

GitLab 管理员可以管理其实例的 GitLab CI/CD 配置。

在新项目中禁用 GitLab CI/CD

在实例中，所有新项目默认启用 GitLab CI/CD。您可以通过修改以下设置，将新项目的 CI/CD 设置为默认禁用：

• gitlab.yml 文件（适用于自行编译安装的实例）。
• gitlab.rb 文件（适用于 Linux 包安装的实例）。

已启用 CI/CD 的现有项目不受影响。此外，此设置仅更改项目的默认值，因此项目所有者仍然可以在项目设置中启用 CI/CD。

对于自行编译安装的实例：

1. 使用编辑器打开 gitlab.yml 文件，并将 builds 设置为 false：

   ## Default project features settings
   default_projects_features:
     issues: true
     merge_requests: true
     wiki: true
     snippets: false
     builds: false

2. 保存 gitlab.yml 文件。

3. 重启 GitLab：

   sudo service gitlab restart

对于 Linux 包安装的实例：

1. 编辑 /etc/gitlab/gitlab.rb 文件并添加以下行：

   gitlab_rails['gitlab_default_projects_features_builds'] = false

2. 保存 /etc/gitlab/gitlab.rb 文件。

3. 重新配置 GitLab：

   sudo gitlab-ctl reconfigure

设置 needs 作业限制

needs 中可定义的最大作业数量默认为 50。

拥有 GitLab Rails 控制台访问权限 的 GitLab 管理员可以选择自定义限制。例如，要将限制设置为 100：

Plan.default.actual_limits.update!(ci_needs_size_limit: 100)

要禁用 needs 依赖项，请将限制设置为 0。这样，配置为使用 needs 的作业的流水线将返回错误 job can only need 0 others。

更改最大计划流水线频率

计划流水线可以使用任何 cron 值进行配置，但它们并不总是在计划的时间精确运行。一个名为 pipeline schedule worker（流水线计划工作器）的内部进程会将所有计划流水线加入队列，但它并非持续运行。该工作器按自己的计划运行，准备启动的计划流水线只有在工作器下次运行时才会被加入队列。计划流水线的运行频率不能高于工作器的运行频率。

流水线计划工作器的默认频率为 3-59/10 * * * *（每十分钟一次，从 0:03、0:13、0:23 等开始）。GitLab.com 的默认频率列在 GitLab.com 设置中。

要更改流水线计划工作器的频率：

1. 在您实例的 gitlab.rb 文件中编辑 gitlab_rails['pipeline_schedule_worker_cron'] 的值。
2. 重新配置 GitLab 以使更改生效。

例如，要将流水线的最大频率设置为每天两次，请将 pipeline_schedule_worker_cron 设置为 cron 值 0 */12 * * *（每天 00:00 和 12:00）。

当许多流水线计划同时运行时，可能会发生额外的延迟。流水线计划工作器以批次方式处理流水线，并在每个批次之间有短暂的延迟，以分散系统负载。这可能导致流水线计划在预定时间之后数分钟才开始。

灾难恢复

在持续停机期间，您可以禁用应用中一些重要但计算开销大的部分，以减轻数据库的压力。

在实例运行器上禁用公平调度

在清除大量积压作业时，您可以临时启用 ci_queueing_disaster_recovery_disable_fair_scheduling 功能标志。此标志会禁用实例运行器上的公平调度，从而减少 jobs/request 端点上的系统资源使用。

启用后，作业将按照它们进入系统的顺序进行处理，而不是在多个项目之间进行平衡。

禁用计算配额强制执行

要禁用实例运行器上的计算分钟配额的强制执行，您可以临时启用 ci_queueing_disaster_recovery_disable_quota 功能标志。此标志会减少 jobs/request 端点上的系统资源使用。

启用后，在过去一小时内创建的作业可以在超出配额的项目中运行。更早的作业已被一个定期的后台工作器 (StuckCiJobsWorker) 取消。