- Auto DevOps
- Enable shared runners for new projects
- Shared runners compute quota
- Enable a project runner for multiple projects
- Add a message for shared runners
- Maximum artifacts size
- Default artifacts expiration
- Keep the latest artifacts for all jobs in the latest successful pipelines
- Archive jobs
- Protect CI/CD variables by default
- Maximum includes
- Default CI/CD configuration file
- Set CI/CD limits
- Enable or disable the pipeline suggestion banner
- Required pipeline configuration
- Package Registry configuration
- Restrict runner registration by all users in an instance
- Restrict runner registration by all members in a group
- Disable runner version management
- Troubleshooting
Continuous Integration and Deployment Admin Area settings
The Admin Area has the instance settings for Auto DevOps, runners, and job artifacts.
Auto DevOps
To enable (or disable) Auto DevOps for all projects:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Check (or uncheck to disable) the box that says Default to Auto DevOps pipeline for all projects.
- Optionally, set up the Auto DevOps base domain which is used for Auto Deploy and Auto Review Apps.
- Select Save changes for the changes to take effect.
From now on, every existing project and newly created ones that don’t have a
.gitlab-ci.yml
use the Auto DevOps pipelines.
If you want to disable it for a specific project, you can do so in its settings.
Enable shared runners for new projects
You can set all new projects to have the instance’s shared runners available by default.
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand Continuous Integration and Deployment.
- Select the Enable shared runners for new projects checkbox.
Any time a new project is created, the shared runners are available.
Shared runners compute quota
As an administrator you can set either a global or namespace-specific limit on the number of compute minutes you can use.
Enable a project runner for multiple projects
If you have already registered a project runner you can assign that runner to other projects.
To enable a project runner for more than one project:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- From the left sidebar, select CI/CD > Runners.
- Select the runner you want to edit.
- In the upper-right corner, select Edit ().
- Under Restrict projects for this runner, search for a project.
- To the left of the project, select Enable.
- Repeat this process for each additional project.
Add a message for shared runners
To display details about the instance’s shared runners in all projects’ runner settings:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand Continuous Integration and Deployment.
-
Enter text, including Markdown if you want, in the Shared runner details field. For example:
To view the rendered details:
- On the left sidebar, select Search or go to and find your project or group.
- Select Settings > CI/CD.
- Expand Runners.
Maximum artifacts size
An administrator can set the maximum size of the job artifacts at:
- The instance level
- The project and group level
For the setting on GitLab.com, see Artifacts maximum size.
The value is in MB, and the default is 100 MB per job. An administrator can change the default value at the:
-
Instance level:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- On the left sidebar, select Settings > CI/CD > Continuous Integration and Deployment.
- Change the value of Maximum artifacts size (MB).
- Select Save changes for the changes to take effect.
-
Group level (this overrides the instance setting):
- Go to the group’s Settings > CI/CD > General Pipelines.
- Change the value of Maximum artifacts size (in MB).
- Select Save changes for the changes to take effect.
-
Project level (this overrides the instance and group settings):
- Go to the project’s Settings > CI/CD > General Pipelines.
- Change the value of maximum artifacts size (in MB).
- Select Save changes for the changes to take effect.
Default artifacts expiration
The default expiration time of the job artifacts
can be set in the Admin Area of your GitLab instance. The syntax of duration is
described in artifacts:expire_in
and the default value is 30 days
.
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Change the value of default expiration time.
- Select Save changes for the changes to take effect.
This setting is set per job and can be overridden in
.gitlab-ci.yml
.
To disable the expiration, set it to 0
. The default unit is in seconds.
Keep the latest artifacts for all jobs in the latest successful pipelines
Introduced in GitLab 13.9.
When enabled (default), the artifacts of the most recent pipeline for each Git ref (branches and tags) are locked against deletion and kept regardless of the expiry time.
When disabled, the latest artifacts for any new successful or fixed pipelines are allowed to expire.
This setting takes precedence over the project level setting. If disabled at the instance level, you cannot enable this per-project.
To disable the setting:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand Continuous Integration and Deployment.
- Clear the Keep the latest artifacts for all jobs in the latest successful pipelines checkbox.
- Select Save changes
When you disable the feature, the latest artifacts do not immediately expire. A new pipeline must run before the latest artifacts can expire and be deleted.
Archive jobs
You can archive old jobs to prevent them from being re-run individually. Archived jobs display a lock icon () and This job is archived at the top of the job log.
Future work is planned to reduce the CI/CD footprint on the system for archived jobs by removing metadata stored in the database needed to run the job. See the CI/CD data time decay blueprint for more details.
To set the duration for which the jobs are considered as old and expired:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Continuous Integration and Deployment section.
- Set the value of Archive jobs.
- Select Save changes for the changes to take effect.
After that time passes, the jobs are archived in the background and no longer able to be
retried. Make it empty to never expire jobs. It has to be no less than 1 day,
for example: 15 days
, 1 month
, 2 years
.
For the value set for GitLab.com, see Scheduled job archiving.
Protect CI/CD variables by default
To set all new CI/CD variables as protected by default:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Select Protect CI/CD variables by default.
Maximum includes
Introduced in GitLab 16.0.
The maximum number of includes per pipeline can be set at the instance level.
The default is 150
.
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Change the value of Maximum includes.
- Select Save changes for the changes to take effect.
Default CI/CD configuration file
Introduced in GitLab 12.5.
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):
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Input the new file and path in the Default CI/CD configuration file field.
- 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.
Set CI/CD limits
- Introduced in GitLab 14.10.
- Maximum number of active pipelines per project setting removed in GitLab 16.0.
You can configure some CI/CD limits from the Admin Area:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Continuous Integration and Deployment section.
- In the CI/CD limits section, you can set the following limits:
- 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 DAG dependencies that a job can have
- Maximum number of runners registered per group
- Maximum number of runners registered per project
- Maximum number of downstream pipelines in a pipeline’s hierarchy tree
Enable or 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 enable or disable the banner:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Select or clear the Enable pipeline suggestion banner checkbox.
- Select Save changes.
Required pipeline configuration
- Moved from GitLab Premium to GitLab Ultimate in 15.0.
- Deprecated in GitLab 15.9.
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, nestedinclude:
keywords (includinginclude:file
,include:local
,include:remote
, andinclude: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:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Required pipeline configuration section.
- Select a CI/CD template from the dropdown list.
- Select Save changes.
Package Registry configuration
Maven Forwarding
GitLab administrators can disable the forwarding of Maven requests to Maven Central.
To disable forwarding Maven requests:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Package Registry section.
- Clear the checkbox Forward Maven package requests to the Maven Registry if the packages are not found in the GitLab Package Registry.
- Select Save changes.
npm Forwarding
GitLab administrators can disable the forwarding of npm requests to npmjs.com.
To disable it:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Package Registry section.
- Clear the checkbox Forward npm package requests to the npm Registry if the packages are not found in the GitLab Package Registry.
- Select Save changes.
PyPI Forwarding
GitLab administrators can disable the forwarding of PyPI requests to pypi.org.
To disable it:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Package Registry section.
- Clear the checkbox Forward PyPI package requests to the PyPI Registry if the packages are not found in the GitLab Package Registry.
- 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:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand the Package Registry section.
- Find the package type you would like to adjust.
- Enter the maximum file size, in bytes.
- Select Save size limits.
Restrict runner registration by all users in an instance
- Introduced in GitLab 14.1.
- Enabled on GitLab.com and self-managed in GitLab 15.5.
GitLab administrators can adjust who is allowed to register runners, by showing and hiding areas of the UI.
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:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand Runners.
- 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.
- 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:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Overview > Groups and find your group.
- Select Edit.
- 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.
- Select Save changes.
Disable runner version management
Introduced in GitLab 15.10.
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:
- On the left sidebar, select Search or go to.
- Select Admin Area.
- Select Settings > CI/CD.
- Expand Runners.
- In the Runner version management section, clear the Fetch GitLab Runner release version data from GitLab.com checkbox.
- Select Save changes.
Troubleshooting
413 Request Entity Too Large
When build jobs fail with the following error, increase the maximum artifacts size.
Uploading artifacts as "archive" to coordinator... too large archive <job-id> responseStatus=413 Request Entity Too Large status=413" at end of a build job on pipeline when trying to store artifacts to <object-storage>.