Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-07-10 21:08:26 +00:00
parent 83f0b8fcb5
commit 0e4f7fdbd5
14 changed files with 52 additions and 34 deletions

View File

@ -19,12 +19,6 @@ swap:
info: information
repo: repository
utilize: use
owner access: the Owner role
owner permission: the Owner role
owner permissions: the Owner role
maintainer access: the Maintainer role
maintainer permission: the Maintainer role
maintainer permissions: the Maintainer role
administrator access: the Administrator role
administrator permission: the Administrator role
administrator permissions: the Administrator role

View File

@ -41,3 +41,9 @@ swap:
developer access: the Developer role
developer permission: the Developer role
developer permissions: the Developer role
maintainer access: the Maintainer role
maintainer permission: the Maintainer role
maintainer permissions: the Maintainer role
owner access: the Owner role
owner permission: the Owner role
owner permissions: the Owner role

View File

@ -105,7 +105,7 @@ This request can help you investigate an unexpected response.
If you want to expose the HTTP exit code, include the `--fail` option:
```shell script
```shell
curl --fail "https://gitlab.example.com/api/v4/does-not-exist"
curl: (22) The requested URL returned error: 404
```

View File

@ -164,7 +164,7 @@ Example response:
Get details of a runner.
The [Maintainer role or higher](../user/permissions.md) is required to get runner details at the
At least the [Maintainer role](../user/permissions.md) is required to get runner details at the
project and group level.
Instance-level runner details via this endpoint are available to all signed in users.

View File

@ -40,8 +40,8 @@ job completes:
- If the job completes in *more than 30 minutes*, the job must use the
[Slack API](https://api.slack.com/) to send data to the channel.
To use the `run` command, you must have the
[Developer role or higher](../../user/permissions.md#project-members-permissions).
To use the `run` command, you must have at least the
[Developer role](../../user/permissions.md#project-members-permissions).
If a job shouldn't be able to be triggered from chat, you can set the job to `except: [chat]`.
## Best practices for ChatOps CI jobs
@ -53,7 +53,7 @@ functions available. Consider these best practices when creating ChatOps jobs:
of the standard CI pipeline.
- If the job is set to `when: manual`, ChatOps creates the pipeline, but the job waits to be started.
- ChatOps provides limited support for access control. If the user triggering the
slash command has the [Developer role or higher](../../user/permissions.md#project-members-permissions)
slash command has at least the [Developer role](../../user/permissions.md#project-members-permissions)
in the project, the job runs. The job itself can use existing
[CI/CD variables](../variables/index.md#predefined-cicd-variables) like
`GITLAB_USER_ID` to perform additional rights validation, but

View File

@ -25,8 +25,8 @@ If you are using a continuous deployment workflow and want to ensure that concur
## Restrict write access to a critical environment
By default, environments can be modified by any team member that has the
[Developer role or higher](../../user/permissions.md#project-members-permissions).
By default, environments can be modified by any team member that has at least the
[Developer role](../../user/permissions.md#project-members-permissions).
If you want to restrict write access to a critical environment (for example a `production` environment),
you can set up [protected environments](protected_environments.md).

View File

@ -42,8 +42,13 @@ Do not use when talking about the product or its features. The documentation des
## Developer
When writing about the Developer role, use a capital "D." Do not use the phrase, "if you are a developer"
to mean someone who is assigned the Developer role. Instead, write it out. "If you are assigned the Developer role..."
When writing about the Developer role:
- Use a capital "D."
- Do not use the phrase, "if you are a developer" to mean someone who is assigned the Developer
role. Instead, write it out. "If you are assigned the Developer role..."
- To describe a situation where the Developer role is the minimum required, use the phrase "at least
the Developer role..."
Do not use "Developer permissions." A user who is assigned the Developer role has a set of associated permissions.
@ -79,8 +84,13 @@ Do not make possessive (GitLab's). This guidance follows [GitLab Brand Guideline
## Guest
When writing about the Guest role, use a capital "G." Do not use the phrase, "if you are a guest"
to mean someone who is assigned the Guest role. Instead, write it out. "If you are assigned the Guest role..."
When writing about the Guest role:
- Use a capital "G."
- Do not use the phrase, "if you are a guest" to mean someone who is assigned the Guest role.
Instead, write it out. "If you are assigned the Guest role..."
- To describe a situation where the Guest role is the minimum required, use the phrase "at
least the Guest role..."
Do not use "Guest permissions." A user who is assigned the Guest role has a set of associated permissions.
@ -102,8 +112,13 @@ Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#v
## Maintainer
When writing about the Maintainer role, use a capital "M." Do not use the phrase, "if you are a maintainer"
to mean someone who is assigned the Maintainer role. Instead, write it out. "If you are assigned the Maintainer role..."
When writing about the Maintainer role:
- Use a capital "M."
- Do not use the phrase, "if you are a maintainer" to mean someone who is assigned the Maintainer
role. Instead, write it out. "If you are assigned the Maintainer role..."
- To describe a situation where the Maintainer role is the minimum required, use the phrase "at
least the Maintainer role..."
Do not use "Maintainer permissions." A user who is assigned the Maintainer role has a set of associated permissions.
@ -133,8 +148,11 @@ Lowercase. If you use **MR** as the acronym, spell it out on first use.
## Owner
When writing about the Owner role, use a capital "O." Do not use the phrase, "if you are an owner"
to mean someone who is assigned the Owner role. Instead, write it out. "If you are assigned the Owner role..."
When writing about the Owner role:
- Use a capital "O."
- Do not use the phrase, "if you are an owner" to mean someone who is assigned the Owner role.
Instead, write it out. "If you are assigned the Owner role..."
Do not use "Owner permissions." A user who is assigned the Owner role has a set of associated permissions.

View File

@ -18,8 +18,8 @@ to use this endpoint.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/245331) in GitLab Free 13.5.
With the [Maintainer role or higher](../../user/permissions.md),
you can view the list of configured alerts integrations by navigating to **Settings > Monitor**
With at least the [Maintainer role](../../user/permissions.md), you can view the list of configured
alerts integrations by navigating to **Settings > Monitor**
in your project's sidebar menu, and expanding the **Alerts** section. The list displays
the integration name, type, and status (enabled or disabled):

View File

@ -239,8 +239,8 @@ When you do, only project members can add and edit comments.
Prerequisite:
- In merge requests, you must have the Developer role or higher.
- In issues, you must have the Reporter role or higher.
- In merge requests, you must have at least the Developer role.
- In issues, you must have at least the Reporter role.
1. On the right sidebar, next to **Lock issue** or **Lock merge request**, select **Edit**.
1. On the confirmation dialog, select **Lock**.
@ -261,7 +261,7 @@ WARNING:
This feature might not be available to you. Check the **version history** note above for details.
You can make a comment confidential, so that it is visible only to project members
who have the Reporter role or higher.
who have at least the Reporter role.
1. Below the comment, select the **Make this comment confidential** checkbox.
1. Select **Comment**.

View File

@ -119,13 +119,13 @@ on an existing group's page.
### Selecting which groups to import
After you have authorized access to the GitLab instance, you are redirected to the GitLab Group
Migration importer page. Your remote GitLab groups, which you have Owner access to, are listed.
Migration importer page. Listed are the remote GitLab groups to which you have the Owner role.
1. By default, the proposed group namespaces match the names as they exist in remote instance, but based on your permissions, you can choose to edit these names before you proceed to import any of them.
1. Select the **Import** button next to any number of groups.
1. The **Status** column shows the import status of each group. You can choose to leave the page open and it will update in real-time.
1. The **Status** column shows the import status of each group. You can choose to leave the page open and it updates in real-time.
1. Once a group has been imported, click its GitLab path to open its GitLab URL.

View File

@ -19,8 +19,8 @@ You can then modify the project files according to your needs.
**Prerequisites:**
- A GitLab group.
- A GitLab user with maintainer permissions to the group.
- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with maintainer permissions to the group.
- A GitLab user with the Maintainer role in the group.
- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with at least the Maintainer role in the group.
- A [Google Cloud Platform (GCP) service account](https://cloud.google.com/docs/authentication/getting-started).
**Steps:**

View File

@ -19,7 +19,7 @@ To add any cluster to GitLab, you need:
- Either a GitLab.com account or an account for a self-managed installation
running GitLab 12.5 or later.
- Maintainer permissions for group-level and project-level clusters.
- The Maintainer role for group-level and project-level clusters.
- Access to the Admin area for instance-level clusters. **(FREE SELF)**
- A Kubernetes cluster.
- Cluster administration access to the cluster with `kubectl`.

View File

@ -28,7 +28,7 @@ repository in automation, it's a simple solution.
A drawback is that your repository could become vulnerable if a remote machine is compromised
by a hacker. You should limit access to the remote machine before a deploy key is
enabled on your repository. A good rule to follow is to provide access only to trusted users,
and make sure that the allowed users have the [Maintainer role or higher](../../permissions.md)
and make sure that the allowed users have at least the [Maintainer role](../../permissions.md)
in the GitLab project.
If this security implication is a concern for your organization,

View File

@ -62,7 +62,7 @@ You can create a release in the user interface, or by using the
We recommend using the API to create releases as one of the last steps in your
CI/CD pipeline.
Only users with the Developer role or higher can create releases.
Only users with at least the Developer role can create releases.
Read more about [Release permissions](#release-permissions).
To create a new release through the GitLab UI:
@ -102,7 +102,7 @@ release tag. When the `released_at` date and time has passed, the badge is autom
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26016) in GitLab 12.6. Asset link editing was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9427) in GitLab 12.10.
Only users with the Developer role or higher can edit releases.
Only users with at least the Developer can edit releases.
Read more about [Release permissions](#release-permissions).
To edit the details of a release: