debian-mirror-gitlab/doc/administration/cicd.md

stage	group	info	type
Verify	Pipeline Execution	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments	howto

GitLab CI/CD instance configuration (FREE SELF)

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 source installations.
• gitlab.rb for Omnibus GitLab 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 installations from source:

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 Omnibus GitLab 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 (FREE SELF)

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 directed acyclic graphs (DAG), 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).