diff --git a/app/assets/javascripts/pages/admin/application_settings/index.js b/app/assets/javascripts/pages/admin/application_settings/index.js index cce30e6b12a..ac255b8d913 100644 --- a/app/assets/javascripts/pages/admin/application_settings/index.js +++ b/app/assets/javascripts/pages/admin/application_settings/index.js @@ -2,6 +2,7 @@ import initSettingsPanels from '~/settings_panels'; import projectSelect from '~/project_select'; import selfMonitor from '~/self_monitor'; import initVariableList from '~/ci_variable_list'; +import initSearchSettings from '~/search_settings'; document.addEventListener('DOMContentLoaded', () => { if (gon.features?.ciInstanceVariablesUi) { @@ -11,4 +12,5 @@ document.addEventListener('DOMContentLoaded', () => { // Initialize expandable settings panels initSettingsPanels(); projectSelect(); + initSearchSettings(); }); diff --git a/app/views/admin/application_settings/ci/_header.html.haml b/app/views/admin/application_settings/ci/_header.html.haml index a54d8ff61e0..aa4cebdb603 100644 --- a/app/views/admin/application_settings/ci/_header.html.haml +++ b/app/views/admin/application_settings/ci/_header.html.haml @@ -8,7 +8,7 @@ %p = _('Variables store information, like passwords and secret keys, that you can use in job scripts. All projects on the instance can use these variables.') - = link_to s_('Learn more.'), help_page_path('ci/variables/README', anchor: 'instance-level-cicd-environment-variables'), target: '_blank', rel: 'noopener noreferrer' + = link_to s_('Learn more.'), help_page_path('ci/variables/README', anchor: 'instance-level-cicd-variables'), target: '_blank', rel: 'noopener noreferrer' %p = _('Variables can be:') %ul diff --git a/app/views/layouts/admin.html.haml b/app/views/layouts/admin.html.haml index 31259b8ac25..85fff22a3b7 100644 --- a/app/views/layouts/admin.html.haml +++ b/app/views/layouts/admin.html.haml @@ -3,4 +3,9 @@ - nav "admin" - @left_sidebar = true +-# This active_nav_link check is also used in `app/views/layouts/nav/sidebar/_admin.html.haml` +- is_application_settings = active_nav_link?(controller: [:application_settings, :integrations]) + +- enable_search_settings if is_application_settings + = render template: "layouts/application" diff --git a/app/views/layouts/nav/sidebar/_admin.html.haml b/app/views/layouts/nav/sidebar/_admin.html.haml index 3d4a00b01a2..f887d335807 100644 --- a/app/views/layouts/nav/sidebar/_admin.html.haml +++ b/app/views/layouts/nav/sidebar/_admin.html.haml @@ -247,6 +247,7 @@ = _('Settings') %ul.sidebar-sub-level-items{ data: { qa_selector: 'admin_sidebar_settings_submenu_content' } } + -# This active_nav_link check is also used in `app/views/layouts/admin.html.haml` = nav_link(controller: [:application_settings, :integrations], html_options: { class: "fly-out-top-item" } ) do = link_to general_admin_application_settings_path do %strong.fly-out-top-item-name diff --git a/config/known_invalid_graphql_queries.yml b/config/known_invalid_graphql_queries.yml index 8c9ba5cb83a..3dc4b10a6a8 100644 --- a/config/known_invalid_graphql_queries.yml +++ b/config/known_invalid_graphql_queries.yml @@ -2,5 +2,4 @@ filenames: - ee/app/assets/javascripts/oncall_schedules/graphql/mutations/update_oncall_schedule_rotation.mutation.graphql - ee/app/assets/javascripts/security_configuration/api_fuzzing/graphql/api_fuzzing_ci_configuration.query.graphql - - ee/app/assets/javascripts/on_demand_scans/graphql/dast_profile_update.mutation.graphql - ee/app/assets/javascripts/security_configuration/api_fuzzing/graphql/create_api_fuzzing_configuration.mutation.graphql diff --git a/doc/administration/maintenance_mode/index.md b/doc/administration/maintenance_mode/index.md index 817cf4488bc..c80088a9dda 100644 --- a/doc/administration/maintenance_mode/index.md +++ b/doc/administration/maintenance_mode/index.md @@ -8,11 +8,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2149) in GitLab Premium 13.9. -In maintenance mode, most write operations are disabled at the application level. -This means that GitLab is effectively in a read-only mode for all non-administrative -users (administrators are still able to edit application settings). Regular users -are able to log in to GitLab, view the interface and perform other read-only -operations, such as `git clone` or `git pull`. +Maintenance mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, Container repositories, etc. + +Once maintenance mode is enabled, in-progress actions will finish relatively quickly since no new actions are coming in, and internal state changes will be minimal. +In that state, various maintenance tasks are easier, and services can be stopped completely or be +further degraded for a much shorter period of time than might otherwise be needed, for example stopping cron jobs and draining queues should be fairly quick. + +Maintenance mode allows most external actions that do not change internal state. On a high-level, HTTP POST, PUT, PATCH, and DELETE requests are blocked and a detailed overview of [how special cases are handled](#rest-api) is available. ## Enable maintenance mode @@ -21,6 +23,7 @@ There are three ways to enable maintenance mode as an administrator: - **Web UI**: 1. Go to **Admin Area > Settings > General**, expand **Maintenance mode**, and toggle **Enable maintenance mode**. You can optionally add a message for the banner as well. + 1. Click **Save** for the changes to take effect. - **API**: @@ -42,6 +45,7 @@ There are three ways to disable maintenance mode: - **Web UI**: 1. Go to **Admin Area > Settings > General**, expand **Maintenance mode**, and toggle **Enable maintenance mode**. + 1. Click **Save** for the changes to take effect. - **API**: @@ -56,31 +60,72 @@ There are three ways to disable maintenance mode: ::Gitlab::CurrentSettings.update_attributes!(maintenance_mode: false) ``` -## Behavior in maintenance mode +## Behavior of GitLab features in maintenance mode When maintenance mode is enabled, a banner is displayed at the top of the page. The banner can be customized with a specific message. An error is displayed when a user tries to perform a write operation that isn't allowed. -The API will return a 403 or 503 error for failed write requests. + +![Maintenance mode banner and error message](maintenance_mode_error_message.png) NOTE: -In some cases, the visual feedback from an action could be misleading, for example -when starring a project, the **Star** button changes to show the **Unstar** action, -however, this is only the frontend update, and it doesn't take into account the -failed status of the POST request. These visual bugs are to be fixed -[in follow-up iterations](https://gitlab.com/gitlab-org/gitlab/-/issues/295197). +In some cases, the visual feedback from an action could be misleading, for example when starring a project, the **Star** button changes to show the **Unstar** action, however, this is only the frontend update, and it doesn't take into account the failed status of the POST request. These visual bugs are to be fixed [in follow-up iterations](https://gitlab.com/gitlab-org/gitlab/-/issues/295197). -### Application settings +### Admin functions -In maintenance mode, admins can edit the application settings. This will allow +Systems administrators can edit the application settings. This will allow them to disable maintenance mode after it's been enabled. -### Logging in/out +### Authentication -All users can log in and out of the GitLab instance. +All users can log in and out of the GitLab instance but no new users can be created. -### CI/CD +If there are [LDAP syncs](../auth/ldap/index.md) scheduled for that time, they will fail since user creation is disabled. Similarly, [user creations based on SAML](../../integration/saml.md#general-setup) will fail. + +### Git actions + +All read-only Git operations will continue to work, for example +`git clone` and `git pull`. All write operations will fail, both through the CLI and Web IDE with the error message: `Git push is not allowed because this GitLab instance is currently in (read-only) maintenance mode.` + +If Geo is enabled, Git pushes to both primary and secondaries will fail. + +### Merge requests, issues, epics + +All write actions except those mentioned above will fail. For example, a user cannot update merge requests or issues. + +### Incoming email + +Creating new issue replies, issues (including new Service Desk issues), merge requests [by email](../incoming_email.md) will fail. + +### Outgoing email + +Notification emails will continue to arrive, but emails that require database writes, like resetting the password, will not arrive. + +### REST API + +For most JSON requests, POST, PUT, PATCH, and DELETE are blocked, and the API returns a 403 response with the error message: `You cannot perform write operations on a read-only instance`. Only the following requests are allowed: + +|HTTP request | Allowed routes | Notes | +|:----:|:--------------------------------------:|:----:| +| POST | `/admin/application_settings/general` | To allow updating application settings in the admin UI | +| PUT | `/api/v4/application/settings` | To allow updating application settings with the API | +| POST | `/users/sign_in` | To allow users to log in. | +| POST | `/users/sign_out`| To allow users to log out. | +| POST | `/oauth/token` | To allow users to log in to a Geo secondary for the first time. | +| POST | `/admin/session`, `/admin/session/destroy` | To allow [Admin mode for GitLab administrators](https://gitlab.com/groups/gitlab-org/-/epics/2158) | +| POST | Paths ending with `/compare`| Git revision routes. | +| POST | `.git/git-upload-pack` | To allow Git pull/clone. | +| POST | `/api/v4/internal` | [internal API routes](../../development/internal_api.md) | +| POST | `/admin/sidekiq` | To allow management of background jobs in the admin UI | +| POST | `/admin/geo` | To allow updating Geo Nodes in the admin UI | +| POST | `/api/v4/geo_replication`| To allow certain Geo-specific admin UI actions on secondary sites | + +### GraphQL API + +`POST /api/graphql` requests are allowed but mutations are blocked with the error message `You cannot perform write operations on a read-only instance`. + +### Continuous Integration In maintenance mode: @@ -92,37 +137,30 @@ In maintenance mode: - Pipelines cannot be started, retried or canceled in maintenance mode. No new jobs can be created either. -Once maintenance mode is disabled, new jobs are picked up again. The jobs that were -in the running state before enabling maintenance mode, will resume, and their logs -will start getting updated again. +Once maintenance mode is disabled, new jobs are picked up again. The jobs that were in the running state before enabling maintenance mode, will resume, and their logs will start getting updated again. -### Git actions +### Deployments -All read-only Git operations will continue to work in maintenance mode, for example -`git clone` and `git pull`, but all write operations will fail, both through the CLI -and Web IDE. - -Geo secondaries are read-only instances that allow Git pushes because they are -proxied to the primary instance. However, in maintenance mode, Git pushes to -both primary and secondaries will fail. - -### Merge requests, issues, epics - -All write actions except those mentioned above will fail. So, in maintenance mode, a user cannot update merge requests, issues, etc. - -### Container Registry - -In maintenance mode, `docker push` is blocked, but `docker pull` is available. - -### Auto Deploys +Deployments won't go through because pipelines will be unfinished. It is recommended to disable auto deploys during maintenance mode, and enable them once maintenance mode is disabled. +#### Terraform integration + +Terraform integration depends on running CI pipelines, hence it will be blocked. + +### Container Registry + +`docker push` will fail with this error: `denied: requested access to the resource is denied`, but `docker pull` will work. + +### Package Registry + +Package Registry will allow you to install but not publish packages. + ### Background jobs -Background jobs (cron jobs, Sidekiq) will continue running as is, because maintenance -mode does not disable any background jobs. +Background jobs (cron jobs, Sidekiq) will continue running as is, because background jobs are not automatically disabled. [During a planned Geo failover](../geo/disaster_recovery/planned_failover.md#prevent-updates-to-the-primary-node), it is recommended that you disable all cron jobs except for those related to Geo. @@ -131,11 +169,37 @@ You can monitor queues and disable jobs in **Admin Area > Monitoring > Backgroun ### Incident management -During Maintenance Mode, [Incident management](../../operations/incident_management/index.md) functions will be limited. The creation of [alerts](../../operations/incident_management/alerts.md) and [incidents](../../operations/incident_management/incidents.md#incident-creation) will be paused entirely. Notifications and paging on alerts and incidents will therefore be disabled. +[Incident management](../../operations/incident_management/index.md) functions will be limited. The creation of [alerts](../../operations/incident_management/alerts.md) and [incidents](../../operations/incident_management/incidents.md#incident-creation) will be paused entirely. Notifications and paging on alerts and incidents will therefore be disabled. + +### Feature flags + +- [Development feature flags](../../development/feature_flags/index.md) cannot be turned on or off through the API, but can be toggled through the Rails console. +- [The feature flag service](../../operations/feature_flags.md) will respond to feature flag checks but feature flags cannot be toggled ### Geo secondaries -The maintenance mode setting will be propagated to the secondary as they sync up. +When primary is in maintenance mode, secondary will also automatically go into maintenance mode. + It is important that you do not disable replication before enabling maintenance mode. -Replication and verification will continue to work in maintenance mode. +Replication and verification will continue to work but proxied Git pushes to primary will not work. + +### Secure features + +Features that depend on creating issues or creating or approving Merge Requests, will not work. + +Exporting a vulnerability list from a Vulnerability Report page will not work. + +Changing the status on a finding or vulnerability object will not work, even though no error is shown in the UI. + +SAST and Secret Detection cannot be initiated because they depend on passing CI jobs to create artifacts. + +## An example use case: a planned failover + +In the use case of [a planned failover](../geo/disaster_recovery/planned_failover.md), a few writes in the primary database are acceptable, since they will be replicated quickly and are not significant in number. + +For the same reason we don't automatically block background jobs when maintenance mode is enabled. + +The resulting database writes are acceptable. Here, the trade-off is between more service degradation and the completion of replication. + +However, during a planned failover, we [ask users to turn off cron jobs that are not related to Geo, manually](../geo/disaster_recovery/planned_failover.md#prevent-updates-to-the-primary-node). In the absence of new database writes and non-Geo cron jobs, new background jobs would either not be created at all or be minimal. diff --git a/doc/administration/maintenance_mode/maintenance_mode_error_message.png b/doc/administration/maintenance_mode/maintenance_mode_error_message.png new file mode 100644 index 00000000000..0a98d36beb8 Binary files /dev/null and b/doc/administration/maintenance_mode/maintenance_mode_error_message.png differ diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql index 233cc427966..8b7af8cc5aa 100644 --- a/doc/api/graphql/reference/gitlab_schema.graphql +++ b/doc/api/graphql/reference/gitlab_schema.graphql @@ -5967,6 +5967,78 @@ type DastProfileRunPayload { pipelineUrl: String } +""" +Autogenerated input type of DastProfileUpdate +""" +input DastProfileUpdateInput { + """ + A unique identifier for the client performing the mutation. + """ + clientMutationId: String + + """ + ID of the scanner profile to be associated. + """ + dastScannerProfileId: DastScannerProfileID + + """ + ID of the site profile to be associated. + """ + dastSiteProfileId: DastSiteProfileID + + """ + The description of the profile. Defaults to an empty string. + """ + description: String = "" + + """ + The project the profile belongs to. + """ + fullPath: ID! + + """ + ID of the profile to be deleted. + """ + id: DastProfileID! + + """ + The name of the profile. + """ + name: String + + """ + Run scan using profile after update. Defaults to false. + """ + runAfterUpdate: Boolean = false +} + +""" +Autogenerated return type of DastProfileUpdate +""" +type DastProfileUpdatePayload { + """ + A unique identifier for the client performing the mutation. + """ + clientMutationId: String + + """ + The updated profile. + """ + dastProfile: DastProfile + + """ + Errors encountered during execution of the mutation. + """ + errors: [String!]! + + """ + The URL of the pipeline that was created. Requires the input argument + `runAfterUpdate` to be set to `true` when calling the mutation, otherwise no + pipeline will be created. + """ + pipelineUrl: String +} + enum DastScanTypeEnum { """ Active DAST scan. This scan will make active attacks against the target site. @@ -16652,6 +16724,7 @@ type Mutation { dastProfileCreate(input: DastProfileCreateInput!): DastProfileCreatePayload dastProfileDelete(input: DastProfileDeleteInput!): DastProfileDeletePayload dastProfileRun(input: DastProfileRunInput!): DastProfileRunPayload + dastProfileUpdate(input: DastProfileUpdateInput!): DastProfileUpdatePayload dastScannerProfileCreate(input: DastScannerProfileCreateInput!): DastScannerProfileCreatePayload dastScannerProfileDelete(input: DastScannerProfileDeleteInput!): DastScannerProfileDeletePayload dastScannerProfileUpdate(input: DastScannerProfileUpdateInput!): DastScannerProfileUpdatePayload diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json index f11ed31c1a7..5a003571b2c 100644 --- a/doc/api/graphql/reference/gitlab_schema.json +++ b/doc/api/graphql/reference/gitlab_schema.json @@ -16233,6 +16233,186 @@ "enumValues": null, "possibleTypes": null }, + { + "kind": "INPUT_OBJECT", + "name": "DastProfileUpdateInput", + "description": "Autogenerated input type of DastProfileUpdate", + "fields": null, + "inputFields": [ + { + "name": "id", + "description": "ID of the profile to be deleted.", + "type": { + "kind": "NON_NULL", + "name": null, + "ofType": { + "kind": "SCALAR", + "name": "DastProfileID", + "ofType": null + } + }, + "defaultValue": null + }, + { + "name": "fullPath", + "description": "The project the profile belongs to.", + "type": { + "kind": "NON_NULL", + "name": null, + "ofType": { + "kind": "SCALAR", + "name": "ID", + "ofType": null + } + }, + "defaultValue": null + }, + { + "name": "name", + "description": "The name of the profile.", + "type": { + "kind": "SCALAR", + "name": "String", + "ofType": null + }, + "defaultValue": null + }, + { + "name": "description", + "description": "The description of the profile. Defaults to an empty string.", + "type": { + "kind": "SCALAR", + "name": "String", + "ofType": null + }, + "defaultValue": "\"\"" + }, + { + "name": "dastSiteProfileId", + "description": "ID of the site profile to be associated.", + "type": { + "kind": "SCALAR", + "name": "DastSiteProfileID", + "ofType": null + }, + "defaultValue": null + }, + { + "name": "dastScannerProfileId", + "description": "ID of the scanner profile to be associated.", + "type": { + "kind": "SCALAR", + "name": "DastScannerProfileID", + "ofType": null + }, + "defaultValue": null + }, + { + "name": "runAfterUpdate", + "description": "Run scan using profile after update. Defaults to false.", + "type": { + "kind": "SCALAR", + "name": "Boolean", + "ofType": null + }, + "defaultValue": "false" + }, + { + "name": "clientMutationId", + "description": "A unique identifier for the client performing the mutation.", + "type": { + "kind": "SCALAR", + "name": "String", + "ofType": null + }, + "defaultValue": null + } + ], + "interfaces": null, + "enumValues": null, + "possibleTypes": null + }, + { + "kind": "OBJECT", + "name": "DastProfileUpdatePayload", + "description": "Autogenerated return type of DastProfileUpdate", + "fields": [ + { + "name": "clientMutationId", + "description": "A unique identifier for the client performing the mutation.", + "args": [ + + ], + "type": { + "kind": "SCALAR", + "name": "String", + "ofType": null + }, + "isDeprecated": false, + "deprecationReason": null + }, + { + "name": "dastProfile", + "description": "The updated profile.", + "args": [ + + ], + "type": { + "kind": "OBJECT", + "name": "DastProfile", + "ofType": null + }, + "isDeprecated": false, + "deprecationReason": null + }, + { + "name": "errors", + "description": "Errors encountered during execution of the mutation.", + "args": [ + + ], + "type": { + "kind": "NON_NULL", + "name": null, + "ofType": { + "kind": "LIST", + "name": null, + "ofType": { + "kind": "NON_NULL", + "name": null, + "ofType": { + "kind": "SCALAR", + "name": "String", + "ofType": null + } + } + } + }, + "isDeprecated": false, + "deprecationReason": null + }, + { + "name": "pipelineUrl", + "description": "The URL of the pipeline that was created. Requires the input argument `runAfterUpdate` to be set to `true` when calling the mutation, otherwise no pipeline will be created.", + "args": [ + + ], + "type": { + "kind": "SCALAR", + "name": "String", + "ofType": null + }, + "isDeprecated": false, + "deprecationReason": null + } + ], + "inputFields": null, + "interfaces": [ + + ], + "enumValues": null, + "possibleTypes": null + }, { "kind": "ENUM", "name": "DastScanTypeEnum", @@ -46493,6 +46673,33 @@ "isDeprecated": false, "deprecationReason": null }, + { + "name": "dastProfileUpdate", + "description": null, + "args": [ + { + "name": "input", + "description": null, + "type": { + "kind": "NON_NULL", + "name": null, + "ofType": { + "kind": "INPUT_OBJECT", + "name": "DastProfileUpdateInput", + "ofType": null + } + }, + "defaultValue": null + } + ], + "type": { + "kind": "OBJECT", + "name": "DastProfileUpdatePayload", + "ofType": null + }, + "isDeprecated": false, + "deprecationReason": null + }, { "name": "dastScannerProfileCreate", "description": null, diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index ce312944cf1..82156c81b16 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -963,6 +963,17 @@ Autogenerated return type of DastProfileRun. | `errors` | String! => Array | Errors encountered during execution of the mutation. | | `pipelineUrl` | String | URL of the pipeline that was created. | +### DastProfileUpdatePayload + +Autogenerated return type of DastProfileUpdate. + +| Field | Type | Description | +| ----- | ---- | ----------- | +| `clientMutationId` | String | A unique identifier for the client performing the mutation. | +| `dastProfile` | DastProfile | The updated profile. | +| `errors` | String! => Array | Errors encountered during execution of the mutation. | +| `pipelineUrl` | String | The URL of the pipeline that was created. Requires the input argument `runAfterUpdate` to be set to `true` when calling the mutation, otherwise no pipeline will be created. | + ### DastScannerProfile Represents a DAST scanner profile. diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md index 08a45714de3..bfc332e35b1 100644 --- a/doc/ci/caching/index.md +++ b/doc/ci/caching/index.md @@ -87,7 +87,7 @@ use one or more of the following: that are only available to a particular project. - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example, different caches on each branch). For that, you can take advantage of the - [CI/CD predefined variables](../variables/README.md#predefined-environment-variables). + [predefined CI/CD variables](../variables/README.md#predefined-cicd-variables). For runners to work with caches efficiently, you must do one of the following: diff --git a/doc/ci/chatops/index.md b/doc/ci/chatops/index.md index 4ec921b4447..48f8e595df6 100644 --- a/doc/ci/chatops/index.md +++ b/doc/ci/chatops/index.md @@ -25,7 +25,7 @@ with the following arguments: - A `` to execute. - The ``. -ChatOps passes the following [CI/CD variables](../variables/README.md#predefined-environment-variables) +ChatOps passes the following [CI/CD variables](../variables/README.md#predefined-cicd-variables) to the job: - `CHAT_INPUT` contains any additional arguments. @@ -55,9 +55,9 @@ functions available. Consider these best practices when creating ChatOps jobs: - ChatOps provides limited support for access control. If the user triggering the slash command has [Developer access or above](../../user/permissions.md#project-members-permissions) in the project, the job runs. The job itself can use existing - [CI/CD variables](../variables/README.md#predefined-environment-variables) like + [CI/CD variables](../variables/README.md#predefined-cicd-variables) like `GITLAB_USER_ID` to perform additional rights validation, but - these variables can be [overridden](../variables/README.md#priority-of-environment-variables). + these variables can be [overridden](../variables/README.md#priority-of-cicd-variables). ### Controlling the ChatOps reply diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md index 3fbbb436c63..a4b45bfd29f 100644 --- a/doc/ci/cloud_deployment/index.md +++ b/doc/ci/cloud_deployment/index.md @@ -38,7 +38,7 @@ Some credentials are required to be able to run `aws` commands: A new **Access key ID** and **Secret access key** are generated. Please take a note of them right away. 1. In your GitLab project, go to **Settings > CI / CD**. Set the following as - [environment variables](../variables/README.md#gitlab-cicd-environment-variables) + [CI/CD variables](../variables/README.md) (see table below): - Access key ID. @@ -141,15 +141,15 @@ After you have these prerequisites ready, follow these steps: ``` You can create your `CI_AWS_ECS_TASK_DEFINITION_FILE` variable as a - [file-typed environment variable](../variables/README.md#custom-environment-variables-of-type-file) instead of a - regular environment variable. If you choose to do so, set the variable value to be the full contents of + [file-typed CI/CD variable](../variables/README.md#custom-cicd-variables-of-type-file) instead of a + regular CI/CD variable. If you choose to do so, set the variable value to be the full contents of the JSON task definition. You can then remove the JSON file from your project. In both cases, make sure that the value for the `containerDefinitions[].name` attribute is the same as the `Container name` defined in your targeted ECS service. WARNING: - `CI_AWS_ECS_TASK_DEFINITION_FILE` takes precedence over `CI_AWS_ECS_TASK_DEFINITION` if both these environment + `CI_AWS_ECS_TASK_DEFINITION_FILE` takes precedence over `CI_AWS_ECS_TASK_DEFINITION` if both these variables are defined within your project. NOTE: @@ -252,12 +252,12 @@ pass three JSON input objects, based on existing templates: CI_AWS_EC2_DEPLOYMENT_FILE: 'aws/create_deployment.json' ``` - - Alternatively, you can provide these JSON objects as [file-typed environment variables](../variables/README.md#custom-environment-variables-of-type-file). - In your project, go to **Settings > CI / CD > Variables** and add - the three variables listed above as file-typed environment variables. - For each variable, set the value to its corresponding JSON object. + - Alternatively, you can provide these JSON objects as [file-typed CI/CD variables](../variables/README.md#custom-cicd-variables-of-type-file). + In your project, go to **Settings > CI/CD > Variables** and add + the three variables listed above as file-typed CI/CD variables. + For each variable, set the value to its corresponding JSON object. -1. Provide the name of the stack you're creating and/or targeting, as an environment variable: +1. Provide the name of the stack you're creating and/or targeting, as a CI/CD variable: ```yaml variables: diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 4025d0d928e..743808c09e1 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -528,7 +528,7 @@ To access private container registries, the GitLab Runner process can use: To define which should be used, the GitLab Runner process reads the configuration in the following order: - `DOCKER_AUTH_CONFIG` variable provided as either: - - A [variable](../variables/README.md#gitlab-cicd-environment-variables) in `.gitlab-ci.yml`. + - A [variable](../variables/README.md) in `.gitlab-ci.yml`. - A project's variables stored on the projects **Settings > CI/CD** page. - `DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the runner. - `config.json` file placed in `$HOME/.docker` directory of the user running GitLab Runner process. @@ -627,7 +627,7 @@ Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`: To configure a single job with access for `registry.example.com:5000`, follow these steps: -1. Create a [variable](../variables/README.md#gitlab-cicd-environment-variables) `DOCKER_AUTH_CONFIG` with the content of the +1. Create a [variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: ```json @@ -702,7 +702,7 @@ To configure credentials store, follow these steps: 1. Make GitLab Runner use it. There are two ways to accomplish this. Either: - Create a - [variable](../variables/README.md#gitlab-cicd-environment-variables) + [variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: @@ -734,7 +734,7 @@ To configure access for `aws_account_id.dkr.ecr.region.amazonaws.com`, follow th Make sure that GitLab Runner can access the credentials. 1. Make GitLab Runner use it. There are two ways to accomplish this. Either: - - Create a [variable](../variables/README.md#gitlab-cicd-environment-variables) + - Create a [variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the Docker configuration file as the value: diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md index b3df1642d6c..2122cf2bf16 100644 --- a/doc/ci/docker/using_kaniko.md +++ b/doc/ci/docker/using_kaniko.md @@ -49,7 +49,7 @@ In the following example, kaniko is used to: The job runs only when a tag is pushed. A `config.json` file is created under `/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the -[environment variables](../variables/README.md#predefined-environment-variables) +[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables) GitLab CI/CD provides. In the last step, kaniko uses the `Dockerfile` under the diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md index b5792c2bbc4..ba73d48dd48 100644 --- a/doc/ci/environments/index.md +++ b/doc/ci/environments/index.md @@ -313,9 +313,9 @@ Dynamic environments are a fundamental part of [Review apps](../review_apps/inde The `name` and `url` keywords for dynamic environments can use most available CI/CD variables, including: -- [Predefined environment variables](../variables/README.md#predefined-environment-variables) -- [Project and group variables](../variables/README.md#gitlab-cicd-environment-variables) -- [`.gitlab-ci.yml` variables](../yaml/README.md#variables) +- [Predefined CI/CD variables](../variables/README.md#predefined-cicd-variables) +- [Project and group CI/CD variables](../variables/README.md) +- [`.gitlab-ci.yml` CI/CD variables](../yaml/README.md#variables) However, you cannot use variables defined: @@ -1025,7 +1025,7 @@ with `review/` would have that particular variable. Some GitLab features can behave differently for each environment. For example, you can -[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-environment-variables). +[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-cicd-variables). In most cases, these features use the _environment specs_ mechanism, which offers an efficient way to implement scoping within each environment group. diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md index 4521c2ed52e..e20e86e8936 100644 --- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md +++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md @@ -191,7 +191,7 @@ option as an argument to `npm run confidence-check` on the command line. However, we still need to tell WebdriverIO which browser is available for it to use. [GitLab CI/CD makes -a number of variables available](../../variables/README.md#predefined-environment-variables) +a number of variables available](../../variables/README.md#predefined-cicd-variables) with information about the current CI job. We can use this information to dynamically set up our WebdriverIO configuration according to the job that is running. More specifically, we can tell WebdriverIO what browser to execute the test on depending on the name of the currently running diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md index 855f3e599f1..d9e99b3fb38 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -119,7 +119,7 @@ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys cat ~/.ssh/id_rsa ``` -Now, let's add it to your GitLab project as a [variable](../../variables/README.md#gitlab-cicd-environment-variables). +Now, let's add it to your GitLab project as a [CI/CD variable](../../variables/README.md). Variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes. They can be added per project by navigating to the project's **Settings** > **CI/CD**. diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md index 9b4a35ff5e2..f8fcb8a0437 100644 --- a/doc/ci/jobs/index.md +++ b/doc/ci/jobs/index.md @@ -150,9 +150,9 @@ additional variables. To access this page, click on the **name** of the manual j the pipeline view, *not* the play (**{play}**) button. This is useful when you want to alter the execution of a job that uses -[custom environment variables](../variables/README.md#custom-environment-variables). +[custom environment variables](../variables/README.md#custom-cicd-variables). Add a variable name (key) and value here to override the value defined in -[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-environment-variables), +[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-cicd-variables), for a single run of the manual job. ![Manual job variables](img/manual_job_variables.png) diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md index 4c62e2a645e..f010773d799 100644 --- a/doc/ci/migration/circleci.md +++ b/doc/ci/migration/circleci.md @@ -265,7 +265,7 @@ test_async: ## Contexts and variables -CircleCI provides [Contexts](https://circleci.com/docs/2.0/contexts/) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [variables](../variables/README.md#group-level-environment-variables) can be stored outside the individual projects, and securely passed into pipelines across multiple projects. +CircleCI provides [Contexts](https://circleci.com/docs/2.0/contexts/) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [variables](../variables/README.md#group-level-cicd-variables) can be stored outside the individual projects, and securely passed into pipelines across multiple projects. ## Orbs diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md index a84fb3fa06f..b4bf0537a40 100644 --- a/doc/ci/multi_project_pipelines.md +++ b/doc/ci/multi_project_pipelines.md @@ -220,7 +220,7 @@ the ones defined in the upstream project take precedence. #### With variable inheritance -You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#inherit-environment-variables) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs). +You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#inherit-cicd-variables) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs). In the upstream pipeline: diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md index d6b9282462d..6bc0d9bddd9 100644 --- a/doc/ci/pipelines/index.md +++ b/doc/ci/pipelines/index.md @@ -77,7 +77,7 @@ You can also configure specific aspects of your pipelines through the GitLab UI. - [Pipeline settings](settings.md) for each project. - [Pipeline schedules](schedules.md). -- [Custom CI/CD variables](../variables/README.md#custom-environment-variables). +- [Custom CI/CD variables](../variables/README.md#custom-cicd-variables). ### Ref Specs for Runners diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index 20916588962..32221b78039 100644 --- a/doc/ci/pipelines/settings.md +++ b/doc/ci/pipelines/settings.md @@ -351,9 +351,9 @@ https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_te ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130) -## Environment Variables +## CI/CD Variables -[Environment variables](../variables/README.md#gitlab-cicd-environment-variables) can be set in an environment to be available to a runner. +[CI/CD variables](../variables/README.md) can be set to be available to a runner.