CI/CD settings

Configure CI/CD settings for your GitLab instance in the Admin area.

The following settings are available:

• Variables: Configure CI/CD variables available to all projects in your instance.
• Continuous Integration and Deployment: Configure settings for Auto DevOps, jobs, artifacts, instance runners, and pipeline features.
• Package registry: Configure package forwarding and file size limits.
• Runners: Configure runner registration, version management, and token settings.
• Job token permissions: Control job token access across projects.
• Job logs: Configure job log settings like incremental logging.

Access continuous integration and deployment settings

Customize CI/CD settings, including Auto DevOps, instance runners, and job artifacts.

To access these settings:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Continuous Integration and Deployment.

Configure Auto DevOps for all projects

Configure Auto DevOps to run for all projects that don’t have a .gitlab-ci.yml file. This applies to both existing projects and any new projects.

To configure Auto DevOps for all projects in your instance:

1. Select the Default to Auto DevOps pipeline for all projects checkbox.
2. Optional. To use Auto Deploy and Auto Review Apps, specify the Auto DevOps base domain.
3. Select Save changes.

Instance runners

Enable instance runners for new projects

Make instance runners available to all new projects by default.

To make instance runners available to new projects:

1. Select the Enable instance runners for new projects checkbox.
2. Select Save changes.

Add details for instance runners

Add explanatory text about the instance runners. This text appears in all projects’ runner settings.

To add instance runner details:

1. Enter text in the Instance runner details field. You can use Markdown formatting.
2. Select Save changes.

To view the rendered details:

1. On the left sidebar, select Search or go to and find your project or group.
2. Select Settings > CI/CD.
3. Expand Runners.

Share project runners with multiple projects

Share a project runner with multiple projects.

Prerequisites:

• You must have a registered project runner.

To share a project runner with multiple projects:

1. On the left sidebar, at the bottom, select Admin.
2. From the left sidebar, select CI/CD > Runners.
3. Select the runner you want to edit.
4. In the upper-right corner, select Edit ( ).
5. Under Restrict projects for this runner, search for a project.
6. To the left of the project, select Enable.
7. Repeat this process for each additional project.

Job artifacts

Control how job artifacts are stored and managed across your GitLab instance.

Set maximum artifacts size

Set size limits for job artifacts to control storage use. Each artifact file in a job has a default maximum size of 100 MB.

Job artifacts defined with artifacts:reports can have different limits. When different limits apply, the smaller value is used.

You can configure artifact size limits for:

• An instance: The base setting that applies to all projects and groups.
• A group: Overrides the instance setting for all projects in the group.
• A project: Overrides both instance and group settings for a specific project.

For GitLab.com limits, see Artifacts maximum size.

To change the maximum artifact size for an instance:

1. Enter a value in the Maximum artifacts size (MB) field.
2. Select Save changes.

To change the maximum artifact size for a group or project:

1. On the left sidebar, select Search or go to and find your project or group.
2. Select Settings > CI/CD.
3. Expand General pipelines
4. Change the value of Maximum artifacts size (in MB).
5. Select Save changes.

Set default artifacts expiration

Set how long job artifacts are kept before being automatically deleted. The default expiration time is 30 days.

The syntax for duration is described in artifacts:expire_in. Individual job definitions can override this default value in the project’s .gitlab-ci.yml file.

Changes to this setting apply only to new artifacts. Existing artifacts keep their original expiration time. For information about manually expiring older artifacts, see the troubleshooting documentation.

To set the default expiration time for job artifacts:

1. Enter a value in the Default artifacts expiration field.
2. Select Save changes.

Keep artifacts from latest successful pipelines

Preserve artifacts from the most recent successful pipeline for each Git ref (branch or tag), regardless of their expiration time.

By default, this setting is turned on.

This setting takes precedence over project settings. If turned off for an instance, it cannot be turned on for individual projects.

When this feature is turned off, existing preserved artifacts don’t immediately expire. A new successful pipeline must run on a branch before its artifacts can expire.

To keep artifacts from the latest successful pipelines:

1. Select the Keep the latest artifacts for all jobs in the latest successful pipelines checkbox.
2. Select Save changes.

To allow artifacts to expire according to their expiration settings, clear the checkbox instead.

Display external redirect warning page

Display a warning page when users view job artifacts through GitLab Pages. This warning alerts about potential security risks from user-generated content.

By default, this setting is turned on.

To display the warning page when viewing job artifacts:

1. Select the Enable the external redirect page for job artifacts checkbox.
2. Select Save changes.

To allow direct access to job artifacts without warnings, clear the checkbox instead.

Jobs

Archive older jobs

Archive older jobs automatically after a specified time period. Archived jobs:

• Display a lock icon ( ) and This job is archived at the top of the job log.
• Cannot be re-run individually.
• Are still visible in job logs.
• Can still be retried.
• Are no longer subject to expiration settings.

The archive duration must be at least 1 day. Examples of valid durations include 15 days, 1 month, and 2 years. Leave this field empty to never archive jobs automatically.

For GitLab.com, see Scheduled job archiving.

To set up job archiving:

1. Enter a value in the Archive jobs field.
2. Select Save changes.

Pipelines

Protect CI/CD variables by default

To set all new CI/CD variables as protected by default:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Select Protect CI/CD variables by default.

Maximum includes

The maximum number of includes per pipeline can be set for the entire instance. The default is 150.

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Change the value of Maximum includes.
4. Select Save changes for the changes to take effect.

Maximum downstream pipeline trigger rate

The maximum number of downstream pipelines that can be triggered per minute (for a given project, user, and commit) can be set for the entire instance. The default value is 0 (no restriction).

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Change the value of Maximum downstream pipeline trigger rate.
4. Select Save changes for the changes to take effect.

Default CI/CD configuration file

The default CI/CD configuration file and path for new projects can be set in the Admin area of your GitLab instance (.gitlab-ci.yml if not set):

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Input the new file and path in the Default CI/CD configuration file field.
4. Select Save changes for the changes to take effect.

It is also possible to specify a custom CI/CD configuration file for a specific project.

Disable the pipeline suggestion banner

By default, a banner displays in merge requests with no pipeline suggesting a walkthrough on how to add one.

To disable the banner:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Clear the Enable pipeline suggestion banner checkbox.
4. Select Save changes.

Disable the migrate from Jenkins banner

By default, a banner shows in merge requests in projects with the Jenkins integration enabled to prompt migration to GitLab CI/CD.

To disable the banner:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Clear the Show the migrate from Jenkins banner checkbox.
4. Select Save changes.

Set CI/CD limits

You can configure some CI/CD limits from the Admin area:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Continuous Integration and Deployment.
4. In the CI/CD limits section, you can set the following limits:
   • Maximum number of instance-level CI/CD variables
   • Maximum size of a dotenv artifact in bytes
   • Maximum number of variables in a dotenv artifact
   • Maximum number of jobs in a single pipeline
   • Total number of jobs in currently active pipelines
   • Maximum number of pipeline subscriptions to and from a project
   • Maximum number of pipeline schedules
   • Maximum number of needs dependencies that a job can have
   • Maximum number of runners created or active in a group during the past seven days
   • Maximum number of runners created or active in a project during the past seven days
   • Maximum number of downstream pipelines in a pipeline’s hierarchy tree

Package registry configuration

Configure package forwarding, package limits, and package file size limits.

To access these settings:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Package registry.

Maven forwarding

GitLab administrators can disable the forwarding of Maven requests to Maven Central.

To disable forwarding Maven requests:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand the Package registry section.
4. Clear the checkbox Forward Maven package requests to the Maven registry if the packages are not found in the GitLab Package registry.
5. Select Save changes.

npm forwarding

GitLab administrators can disable the forwarding of npm requests to npmjs.com.

To disable it:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand the Package registry section.
4. Clear the checkbox Forward npm package requests to the npm registry if the packages are not found in the GitLab package registry.
5. Select Save changes.

PyPI forwarding

GitLab administrators can disable the forwarding of PyPI requests to pypi.org.

To disable it:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand the Package registry section.
4. Clear the checkbox Forward PyPI package requests to the PyPI registry if the packages are not found in the GitLab package registry.
5. Select Save changes.

Package file size limits

GitLab administrators can adjust the maximum allowed file size for each package type.

To set the maximum file size:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand the Package registry section.
4. Find the package type you would like to adjust.
5. Enter the maximum file size, in bytes.
6. Select Save size limits.

Runners

Configure runner version management and registration settings.

To access these settings:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Runners.

Disable runner version management

By default, GitLab instances periodically fetch official runner version data from GitLab.com to determine whether the runners need upgrades.

To disable your instance fetching this data:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Runners.
4. In the Runner version management section, clear the Fetch GitLab Runner release version data from GitLab.com checkbox.
5. Select Save changes.

Restrict runner registration by all users in an instance

GitLab administrators can adjust who is allowed to register runners, by showing and hiding areas of the UI. This setting does not affect the ability to create a runner from the UI or through an authenticated API call.

When the registration sections are hidden in the UI, members of the project or group must contact administrators to enable runner registration in the group or project. If you plan to prevent registration, ensure users have access to the runners they need to run jobs.

By default, all members of a project and group are able to register runners.

To restrict all users in an instance from registering runners:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Runners.
4. In the Runner registration section, clear the Members of the project can register runners and Members of the group can register runners checkboxes to remove runner registration from the UI.
5. Select Save changes.

Restrict runner registration by all members in a group

Prerequisites:

• Runner registration must be enabled for all users in the instance.

GitLab administrators can adjust group permissions to restrict runner registration by group members.

To restrict runner registration by members in a specific group:

1. On the left sidebar, at the bottom, select Admin.
2. Select Overview > Groups and find your group.
3. Select Edit.
4. Clear the New group runners can be registered checkbox if you want to disable runner registration by all members in the group. If the setting is read-only, you must enable runner registration for the instance.
5. Select Save changes.

Allow runner registration tokens

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Runners.
4. Select the Allow runner registration token checkbox.

Job token permissions

Configure CI/CD job token settings for all projects.

To access these settings:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Job token permissions.

Enforce job token allowlist

You can configure the CI/CD job token access setting for all projects from the Admin area.

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand the Job token permissions section.
4. Enable Enable and enforce job token allowlist for all projects setting to require all projects to control job token access with the allowlist.

Job logs

Configure CI job log settings for all projects.

To access these settings:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Job logs.

Incremental logging

Incremental logging uses Redis instead of disk space for temporary caching of job logs. When turned on, archived job logs are incrementally uploaded to object storage. For more information, see incremental logging.

Prerequisites:

• You must configure object storage for CI/CD artifacts, logs, and builds.

To turn on incremental logging for all projects:

1. On the left sidebar, at the bottom, select Admin.
2. Select Settings > CI/CD.
3. Expand Job logs.
4. Select the Turn on incremental logging checkbox.
5. Select Save changes.

Required pipeline configuration (deprecated)

You can set a CI/CD template as a required pipeline configuration for all projects on a GitLab instance. You can use a template from:

• The default CI/CD templates.

• A custom template stored in an instance template repository.

  When you use a configuration defined in an instance template repository, nested include: keywords (including include:file, include:local, include:remote, and include:template) do not work.

The project CI/CD configuration merges into the required pipeline configuration when a pipeline runs. The merged configuration is the same as if the required pipeline configuration added the project configuration with the include keyword. To view a project’s full merged configuration, View full configuration in the pipeline editor.

To select a CI/CD template for the required pipeline configuration:

1. On the left sidebar, at the bottom, select Admin Area.
2. Select Settings > CI/CD.
3. Expand the Required pipeline configuration section.
4. Select a CI/CD template from the dropdown list.
5. Select Save changes.