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

Docs: adere ssot

Browse source
This commit is contained in:
Marcia Ramos 2019-07-29 04:10:24 +00:00 committed by Evan Read
parent 7476910fc1
commit f1b6395cf9
3 changed files with 61 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
doc/user/project/protected_branches.md
View file

@ -1,3 +1,7 @@
---
type: reference, howto
---
# Protected Branches
[Permissions](../permissions.md) in GitLab are fundamentally defined around the
@ -9,13 +13,13 @@ created protected branches.
By default, a protected branch does four simple things:
- it prevents its creation, if not already created, from everybody except users
with Maintainer permission
- it prevents pushes from everybody except users with Maintainer permission
- it prevents **anyone** from force pushing to the branch
- it prevents **anyone** from deleting the branch
- It prevents its creation, if not already created, from everybody except users
with Maintainer permission.
- It prevents pushes from everybody except users with Maintainer permission.
- It prevents **anyone** from force pushing to the branch.
- It prevents **anyone** from deleting the branch.
>**Note**:
NOTE: **Note:**
A GitLab admin is allowed to push to the protected branches.
See the [Changelog](#changelog) section for changes over time.
@ -68,7 +72,7 @@ they are set to "Maintainers" by default.
## Restricting push and merge access to certain users **(STARTER)**
> This feature was [introduced][ce-5081] in [GitLab Starter][ee] 8.11.
> [Introduced][ce-5081] in [GitLab Starter][ee] 8.11.
With GitLab Enterprise Edition you can restrict access to protected branches
by choosing a role (Maintainers, Developers) as well as certain users. From the
@ -174,11 +178,21 @@ for details about the pipelines security model.
- Allow developers to merge into a protected branch without having push access [gitlab-org/gitlab-ce!4892][ce-4892]
- Allow specifying protected branches using wildcards [gitlab-org/gitlab-ce!4665][ce-4665]
---
[ce-4665]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4665 "Allow specifying protected branches using wildcards"
[ce-4892]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4892 "Allow developers to merge into a protected branch without having push access"
[ce-5081]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5081 "Allow creating protected branches that can't be pushed to"
[ce-21393]: https://gitlab.com/gitlab-org/gitlab-ce/issues/21393
[perm]: ../permissions.md
[ee]: https://about.gitlab.com/pricing/
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->

26
doc/user/project/protected_tags.md
View file

@ -1,3 +1,7 @@
---
type: reference, howto
---
# Protected Tags
> [Introduced][ce-10356] in GitLab 9.1.
@ -14,19 +18,19 @@ Protected tags will prevent anyone from updating or deleting the tag, as and wil
To protect a tag, you need to have at least Maintainer permission level.
1. Navigate to the project's Settings -> Repository page
1. Navigate to the project's **Settings > Repository**:
![Repository Settings](img/project_repository_settings.png)
1. From the **Tag** dropdown menu, select the tag you want to protect or type and click `Create wildcard`. In the screenshot below, we chose to protect all tags matching `v*`.
1. From the **Tag** dropdown menu, select the tag you want to protect or type and click **Create wildcard**. In the screenshot below, we chose to protect all tags matching `v*`:
![Protected tags page](img/protected_tags_page.png)
1. From the `Allowed to create` dropdown, select who will have permission to create matching tags and then click `Protect`.
1. From the **Allowed to create** dropdown, select who will have permission to create matching tags and then click **Protect**:
![Allowed to create tags dropdown](img/protected_tags_permissions_dropdown.png)
1. Once done, the protected tag will appear in the "Protected tags" list.
1. Once done, the protected tag will appear in the **Protected tags** list:
![Protected tags list](img/protected_tags_list.png)
@ -45,13 +49,23 @@ matching the wildcard. For example:
Two different wildcards can potentially match the same tag. For example,
`*-stable` and `production-*` would both match a `production-stable` tag.
In that case, if _any_ of these protected tags have a setting like
"Allowed to create", then `production-stable` will also inherit this setting.
**Allowed to create**, then `production-stable` will also inherit this setting.
If you click on a protected tag's name, you will be presented with a list of
all matching tags:
![Protected tag matches](img/protected_tag_matches.png)
---
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
[ce-10356]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10356 "Protected Tags"

20
doc/user/project/quick_actions.md
View file

@ -1,4 +1,8 @@
# GitLab quick actions
---
type: reference
---
# GitLab Quick Actions
Quick actions are textual shortcuts for common actions on issues, epics, merge requests,
and commits that are usually done by clicking buttons or dropdowns in GitLab's UI.
@ -7,7 +11,7 @@ in comments of issues, epics, merge requests, and commits. Each command should b
on a separate line in order to be properly detected and executed. Once executed,
the commands are removed from the text body and not visible to anyone else.
## Quick actions for issues and merge requests
## Quick Actions for issues and merge requests
The following quick actions are applicable to both issues and merge requests threads,
discussions, and descriptions:
@ -96,3 +100,15 @@ The following quick actions are applicable for epics threads and description:
| `/remove_child_epic <&epic | group&epic | Epic URL>` | Removes child epic from epic ([introduced in GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-ee/issues/7330)) |
| `/parent_epic <&epic | group&epic | Epic URL>` | Sets parent epic to epic ([introduced in GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-ee/issues/10556)) |
| `/remove_parent_epic` | Removes parent epic from epic ([introduced in GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-ee/issues/10556)) |
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->