极狐 GitLab

极狐GitLab CI/CD 实例配置

Tier: 基础版,专业版,旗舰版

Offering: 私有化部署

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

在新项目中禁用极狐GitLab CI/CD#

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

  • 对于自编译安装,修改 gitlab.yml
  • 对于 Linux 软件包安装,修改 gitlab.rb

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

对于自编译安装:

  1. 用编辑器打开 gitlab.yml,并将 builds 设置为 false

    yaml
    1## Default project features settings 2default_projects_features: 3 issues: true 4 merge_requests: true 5 wiki: true 6 snippets: false 7 builds: false
  2. 保存 gitlab.yml 文件。

  3. 重启极狐GitLab:

    shell
    sudo service gitlab restart

对于 Linux 软件包安装:

  1. 编辑 /etc/gitlab/gitlab.rb 并添加以下行:

    ruby
    gitlab_rails['gitlab_default_projects_features_builds'] = false
  2. 保存 /etc/gitlab/gitlab.rb 文件。

  3. 重新配置极狐GitLab:

    shell
    sudo gitlab-ctl reconfigure

设置 needs 作业限制#

Tier: 基础版,专业版,旗舰版

Offering: 私有化部署

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

访问极狐GitLab Rails 控制台权限的极狐GitLab 管理员可以自定义限制。例如,要将限制设置为 100

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

要禁用 needs 依赖项,请将限制设置为 0。配置为使用 needs 的作业的流水线随后会返回错误 作业只能依赖 0 个其他作业

更改最大流水线调度频率#

计划流水线可以配置为任何 cron 值,但它们并不总是完全按照调度时间运行。有一个内部过程,称为 流水线调度工作进程,它对所有计划的流水线进行排队,但不会连续运行。该工作进程按照自己的计划运行,准备启动的计划流水线只会在工作进程下一次运行时排队。计划流水线的运行频率不能超过工作进程的频率。

默认的流水线调度工作进程频率是 3-59/10 * * * *(每十分钟一次,从 0:030:130:23 等时间开始)。JihuLab.com 的默认频率列在 JihuLab.com 设置 中。

要更改流水线调度工作进程的频率:

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

例如,要将流水线的最大频率设置为每天两次,可将 pipeline_schedule_worker_cron 设置为 cron 值 0 */12 * * *(每天 00:0012:00)。

当多个计划流水线同时运行时,可能会出现额外的延迟。流水线调度工作进程以批次方式处理流水线,批次之间有短暂的延迟,以均衡系统负载。这可能导致计划流水线在计划时间之后几分钟到一个多小时后才开始运行,具体取决于系统负载。

灾难恢复#

在持续停机期间,您可以禁用一些重要但计算成本高昂的应用程序部分以减轻数据库压力。

禁用实例 Runner 上的公平调度#

当清理大量积压作业时,您可以临时启用 ci_queueing_disaster_recovery_disable_fair_scheduling 功能标志。该标志会禁用实例 Runner 上的公平调度,从而减少 jobs/request 端点的系统资源使用。

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

禁用计算配额执行#

要禁用实例 Runner 上的计算分钟配额执行,您可以临时启用 ci_queueing_disaster_recovery_disable_quota 功能标志。该标志可减少 jobs/request 端点的系统资源使用。

启用后,最后一小时内创建的作业可以在超出配额的项目中运行。更早的作业已由周期性的后台工作进程 (StuckCiJobsWorker) 取消。