• Disable GitLab CI/CD in new projects
• Set the needs job limit
• Change maximum scheduled pipeline frequency
• Disaster recovery
  • Disable fair scheduling on instance runners
  • Disable compute quota enforcement

GitLab CI/CD instance configuration

GitLab administrators can manage the GitLab CI/CD configuration for their instance.

Disable GitLab CI/CD in new projects

GitLab CI/CD is enabled by default in all new projects on an instance. You can set CI/CD to be disabled by default in new projects by modifying the settings in:

• gitlab.yml for self-compiled installations.
• gitlab.rb for Linux package installations.

Existing projects that already had CI/CD enabled are unchanged. Also, this setting only changes the project default, so project owners can still enable CI/CD in the project settings.

For self-compiled installations:

1. Open gitlab.yml with your editor and set builds to false:

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

2. Save the gitlab.yml file.

3. Restart GitLab:

   sudo service gitlab restart
   

For Linux package installations:

1. Edit /etc/gitlab/gitlab.rb and add this line:

   gitlab_rails['gitlab_default_projects_features_builds'] = false
   

2. Save the /etc/gitlab/gitlab.rb file.

3. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure
   

Set the needs job limit

The maximum number of jobs that can be defined in needs defaults to 50.

A GitLab administrator with access to the GitLab Rails console can choose a custom limit. For example, to set the limit to 100:

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

To disable needs dependencies, set the limit to 0. Pipelines with jobs configured to use needs then return the error job can only need 0 others.

Change maximum scheduled pipeline frequency

Scheduled pipelines can be configured with any cron value, but they do not always run exactly when scheduled. An internal process, called the pipeline schedule worker, queues all the scheduled pipelines, but does not run continuously. The worker runs on its own schedule, and scheduled pipelines that are ready to start are only queued the next time the worker runs. Scheduled pipelines can’t run more frequently than the worker.

The default frequency of the pipeline schedule worker is 3-59/10 * * * * (every ten minutes, starting with 0:03, 0:13, 0:23, and so on). The default frequency for GitLab.com is listed in the GitLab.com settings.

To change the frequency of the pipeline schedule worker:

1. Edit the gitlab_rails['pipeline_schedule_worker_cron'] value in your instance’s gitlab.rb file.
2. Reconfigure GitLab for the changes to take effect.

For example, to set the maximum frequency of pipelines to twice a day, set pipeline_schedule_worker_cron to a cron value of 0 */12 * * * (00:00 and 12:00 every day).

Disaster recovery

You can disable some important but computationally expensive parts of the application to relieve stress on the database during ongoing downtime.

Disable fair scheduling on instance runners

When clearing a large backlog of jobs, you can temporarily enable the ci_queueing_disaster_recovery_disable_fair_scheduling feature flag. This flag disables fair scheduling on instance runners, which reduces system resource usage on the jobs/request endpoint.

When enabled, jobs are processed in the order they were put in the system, instead of balanced across many projects.

Disable compute quota enforcement

To disable the enforcement of compute minutes quotas on instance runners, you can temporarily enable the ci_queueing_disaster_recovery_disable_quota feature flag. This flag reduces system resource usage on the jobs/request endpoint.

When enabled, jobs created in the last hour can run in projects which are out of quota. Earlier jobs are already canceled by a periodic background worker (StuckCiJobsWorker).