1--- 2stage: Verify 3group: Pipeline Execution 4info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments 5type: reference 6--- 7 8# Continuous Integration and Deployment Admin Area settings **(FREE SELF)** 9 10The [Admin Area](index.md) has the instance settings for Auto DevOps, runners, and 11job artifacts. 12 13## Auto DevOps 14 15To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md) 16for all projects: 17 181. On the top bar, select **Menu > Admin**. 191. On the left sidebar, select **Settings > CI/CD**. 201. Check (or uncheck to disable) the box that says **Default to Auto DevOps pipeline for all projects**. 211. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/requirements.md#auto-devops-base-domain) 22 which is used for Auto Deploy and Auto Review Apps. 231. Hit **Save changes** for the changes to take effect. 24 25From now on, every existing project and newly created ones that don't have a 26`.gitlab-ci.yml`, uses the Auto DevOps pipelines. 27 28If you want to disable it for a specific project, you can do so in 29[its settings](../../../topics/autodevops/index.md#enable-or-disable-auto-devops). 30 31## Shared runner details 32 33To display details about the instance's shared runners in all projects' 34runner settings: 35 361. On the top bar, select **Menu > Admin**. 371. On the left sidebar, select **Settings > CI/CD**. 381. Expand **Continuous Integration and Deployment**. 391. Enter your shared runner details in the **Shared runner details** field. 40 41You can use [Markdown](../../markdown.md) for improved formatting. To see the rendered 42details: 43 441. On the top bar, select **Menu > Project** and select any group or project. 451. On the left sidebar, select **Settings > CI/CD**. 461. Expand **Runners**. 47 48![Shared runner details example](img/continuous_integration_shared_runner_details_v14_0.png) 49 50## Maximum artifacts size 51 52The maximum size of the [job artifacts](../../../administration/job_artifacts.md) 53can be set at: 54 55- The instance level. 56- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/21688), the project and group level. 57 58The value is: 59 60- In *MB* and the default is 100MB per job. 61- [Set to 1G](../../gitlab_com/index.md#gitlab-cicd) on GitLab.com. 62 63To change it at the: 64 65- Instance level: 66 67 1. On the top bar, select **Menu > Admin**. 68 1. On the left sidebar, select **Settings > CI/CD**. 69 1. Change the value of maximum artifacts size (in MB). 70 1. Click **Save changes** for the changes to take effect. 71 72- Group level (this overrides the instance setting): 73 74 1. Go to the group's **Settings > CI/CD > General Pipelines**. 75 1. Change the value of **maximum artifacts size (in MB)**. 76 1. Click **Save changes** for the changes to take effect. 77 78- Project level (this overrides the instance and group settings): 79 80 1. Go to the project's **Settings > CI/CD > General Pipelines**. 81 1. Change the value of **maximum artifacts size (in MB)**. 82 1. Click **Save changes** for the changes to take effect. 83 84NOTE: 85The setting at all levels is only available to GitLab administrators. 86 87## Default artifacts expiration 88 89The default expiration time of the [job artifacts](../../../administration/job_artifacts.md) 90can be set in the Admin Area of your GitLab instance. The syntax of duration is 91described in [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in) 92and the default value is `30 days`. 93 941. On the top bar, select **Menu > Admin**. 951. On the left sidebar, select **Settings > CI/CD**. 961. Change the value of default expiration time. 971. Click **Save changes** for the changes to take effect. 98 99This setting is set per job and can be overridden in 100[`.gitlab-ci.yml`](../../../ci/yaml/index.md#artifactsexpire_in). 101To disable the expiration, set it to `0`. The default unit is in seconds. 102 103NOTE: 104Any changes to this setting applies to new artifacts only. The expiration time is not 105be updated for artifacts created before this setting was changed. 106The administrator may need to manually search for and expire previously-created 107artifacts, as described in the [troubleshooting documentation](../../../administration/troubleshooting/gitlab_rails_cheat_sheet.md#remove-artifacts-more-than-a-week-old). 108 109## Keep the latest artifacts for all jobs in the latest successful pipelines 110 111> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50889) in GitLab 13.9. 112 113When enabled (default), the artifacts of the most recent pipeline for each Git ref 114([branches and tags](https://git-scm.com/book/en/v2/Git-Internals-Git-References)) 115are locked against deletion and kept regardless of the expiry time. 116 117When disabled, the latest artifacts for any **new** successful or fixed pipelines 118are allowed to expire. 119 120This setting takes precedence over the [project level setting](../../../ci/pipelines/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs). 121If disabled at the instance level, you cannot enable this per-project. 122 123To disable the setting: 124 1251. On the top bar, select **Menu > Admin**. 1261. On the left sidebar, select **Settings > CI/CD**. 1271. Expand **Continuous Integration and Deployment**. 1281. Clear the **Keep the latest artifacts for all jobs in the latest successful pipelines** checkbox. 1291. Click **Save changes** 130 131When you disable the feature, the latest artifacts do not immediately expire. 132A new pipeline must run before the latest artifacts can expire and be deleted. 133 134NOTE: 135All application settings have a [customizable cache expiry interval](../../../administration/application_settings_cache.md) which can delay the settings affect. 136 137## Shared runners pipeline minutes quota **(PREMIUM SELF)** 138 139> [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9. 140 141If you have enabled shared runners for your GitLab instance, you can limit their 142usage by setting a maximum number of pipeline minutes that a group can use on 143shared runners per month. Setting this to `0` (default value) grants 144unlimited pipeline minutes. While build limits are stored as minutes, the 145counting is done in seconds. Usage resets on the first day of each month. 146On GitLab.com, the quota is calculated based on your 147[subscription plan](../../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes). 148 149To change the pipelines minutes quota: 150 1511. On the top bar, select **Menu > Admin**. 1521. On the left sidebar, select **Settings > CI/CD**. 1531. Expand **Continuous Integration and Deployment**. 1541. In the **Pipeline minutes quota** box, enter the maximum number of minutes. 1551. Click **Save changes** for the changes to take effect. 156 157While the setting in the Admin Area has a global effect, as an administrator you can 158also change each group's pipeline minutes quota to override the global value. 159 1601. Navigate to the **Admin Area > Overview > Groups** and hit the **Edit** 161 button for the group you wish to change the pipeline minutes quota. 1621. In the **Pipeline Minutes Quota** box, enter the maximum number of minutes. 1631. Click **Save changes** for the changes to take effect. 164 165Once saved, you can see the build quota in the group settings. 166The quota can also be viewed in the project settings if shared runners 167are enabled. 168 169![Project admin information](img/admin_project_quota_view.png) 170 171You can see an overview of the pipeline minutes quota of all projects of 172a group in the **Usage Quotas** page available to the group page settings list. 173 174![Group pipelines quota](img/group_pipelines_quota.png) 175 176## Archive jobs 177 178Archiving jobs is useful for reducing the CI/CD footprint on the system by 179removing some of the capabilities of the jobs (metadata needed to run the job), 180but persisting the traces and artifacts for auditing purposes. 181 182To set the duration for which the jobs are considered as old and expired: 183 1841. On the top bar, select **Menu > Admin**. 1851. On the left sidebar, select **Settings > CI/CD**. 1861. Expand the **Continuous Integration and Deployment** section. 1871. Set the value of **Archive jobs**. 1881. Hit **Save changes** for the changes to take effect. 189 190After that time passes, the jobs are archived and no longer able to be 191retried. Make it empty to never expire jobs. It has to be no less than 1 day, 192for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>. 193 194As of June 22, 2020 the [value is set](../../gitlab_com/index.md#gitlab-cicd) to 3 months on GitLab.com. Jobs created before that date were archived after September 22, 2020. 195 196## Protect CI/CD variables by default 197 198To set all new [CI/CD variables](../../../ci/variables/index.md) as 199[protected](../../../ci/variables/index.md#protect-a-cicd-variable) by default: 200 2011. On the top bar, select **Menu > Admin**. 2021. On the left sidebar, select **Settings > CI/CD**. 2031. Select **Protect CI/CD variables by default**. 204 205## Default CI/CD configuration file 206 207> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18073) in GitLab 12.5. 208 209The default CI/CD configuration file and path for new projects can be set in the Admin Area 210of your GitLab instance (`.gitlab-ci.yml` if not set): 211 2121. On the top bar, select **Menu > Admin**. 2131. On the left sidebar, select **Settings > CI/CD**. 2141. Input the new file and path in the **Default CI/CD configuration file** field. 2151. Hit **Save changes** for the changes to take effect. 216 217It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file). 218 219## Enable or disable the pipeline suggestion banner 220 221By default, a banner displays in merge requests with no pipeline suggesting a 222walkthrough on how to add one. 223 224![Suggest pipeline banner](img/suggest_pipeline_banner_v14_5.png) 225 226To enable or disable the banner: 227 2281. On the top bar, select **Menu > Admin**. 2291. On the left sidebar, select **Settings > CI/CD**. 2301. Select or clear the **Enable pipeline suggestion banner** checkbox. 2311. Select **Save changes**. 232 233## Required pipeline configuration **(PREMIUM SELF)** 234 235NOTE: 236An alternative [compliance solution](../../project/settings/index.md#compliance-pipeline-configuration) 237is available. We recommend this alternative solution because it provides greater flexibility, 238allowing required pipelines to be assigned to specific compliance framework labels. 239 240You can set a [CI/CD template](../../../ci/examples/index.md#cicd-templates) 241as a required pipeline configuration for all projects on a GitLab instance. You can 242use a template from: 243 244- The default CI/CD templates. 245- A custom template stored in an [instance template repository](instance_template_repository.md). 246 247 NOTE: 248 When you use a configuration defined in an instance template repository, 249 nested [`include:`](../../../ci/yaml/index.md#include) keywords 250 (including `include:file`, `include:local`, `include:remote`, and `include:template`) 251 [do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345). 252 253The project CI/CD configuration merges into the required pipeline configuration when 254a pipeline runs. The merged configuration is the same as if the required pipeline configuration 255added the project configuration with the [`include` keyword](../../../ci/yaml/index.md#include). 256To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration) 257in the pipeline editor. 258 259To select a CI/CD template for the required pipeline configuration: 260 2611. On the top bar, select **Menu > Admin**. 2621. On the left sidebar, select **Settings > CI/CD**. 2631. Expand the **Required pipeline configuration** section. 2641. Select a CI/CD template from the dropdown. 2651. Click **Save changes**. 266 267## Package Registry configuration 268 269### npm Forwarding **(PREMIUM SELF)** 270 271GitLab administrators can disable the forwarding of npm requests to [npmjs.com](https://www.npmjs.com/). 272 273To disable it: 274 2751. On the top bar, select **Menu > Admin**. 2761. On the left sidebar, select **Settings > CI/CD**. 2771. Expand the **Package Registry** section. 2781. Clear the checkbox **Forward npm package requests to the npm Registry if the packages are not found in the GitLab Package Registry**. 2791. Select **Save changes**. 280 281### PyPI Forwarding **(PREMIUM SELF)** 282 283GitLab administrators can disable the forwarding of PyPI requests to [pypi.org](https://pypi.org/). 284 285To disable it: 286 2871. On the top bar, select **Menu > Admin**. 2881. On the left sidebar, select **Settings > CI/CD**. 2891. Expand the **Package Registry** section. 2901. Clear the checkbox **Forward PyPI package requests to the PyPI Registry if the packages are not found in the GitLab Package Registry**. 2911. Select **Save changes**. 292 293### Package file size limits 294 295GitLab administrators can adjust the maximum allowed file size for each package type. 296 297To set the maximum file size: 298 2991. On the top bar, select **Menu > Admin**. 3001. On the left sidebar, select **Settings > CI/CD**. 3011. Expand the **Package Registry** section. 3021. Find the package type you would like to adjust. 3031. Enter the maximum file size, in bytes. 3041. Click **Save size limits**. 305 306## Runner registration 307 308> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22225) in GitLab 14.1. 309> - [Deployed behind a feature flag](../../feature_flags.md), disabled by default. 310> - Disabled on GitLab.com. 311> - Not recommended for production use. 312> - To use in GitLab self-managed instances, ask a GitLab administrator to enable it. 313 314GitLab administrators can adjust who is allowed to register runners, by showing and hiding areas of the UI. 315 316By default, all members of a project and group are able to register runners. 317 318To change this: 319 3201. On the top bar, select **Menu > Admin**. 3211. Go to **Settings > CI/CD**. 3221. Expand the **Runner registration** section. 3231. Select the desired options. 3241. Click **Save changes**. 325 326When the registration sections are hidden in the UI, members of the project or group that need to register runners must contact the administrators. 327 328This feature is currently behind a feature flag. 329To enable it: 330 331**In Omnibus installations:** 332 3331. Enter the Rails console: 334 335 ```shell 336 sudo gitlab-rails console 337 ``` 338 3391. Flip the switch and enable the feature flag: 340 341 ```ruby 342 Feature.enable(:runner_registration_control) 343 ``` 344 345## Troubleshooting 346 347### 413 Request Entity Too Large 348 349When build jobs fail with the following error, 350increase the [maximum artifacts size](#maximum-artifacts-size). 351 352```plaintext 353Uploading 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>. 354``` 355