If you configure multiple LDAP servers, use a unique naming convention for the `label` section of each entry. That label is used as the display name of the tab shown on the sign-in page.
## User sync **(STARTER ONLY)**
## User sync **(PREMIUM SELF)**
Once per day, GitLab runs a worker to check and update GitLab
users against LDAP.
...
...
@@ -546,7 +546,7 @@ The LDAP sync process:
- Updates existing users.
- Creates new users on first sign in.
### Adjusting LDAP user sync schedule **(STARTER ONLY)**
### Adjusting LDAP user sync schedule **(PREMIUM SELF)**
By default, GitLab runs a worker once per day at 01:30 a.m. server time to
check and update GitLab users against LDAP.
...
...
@@ -579,7 +579,7 @@ sync to run once every 12 hours at the top of the hour.
1.[Restart GitLab](../../restart_gitlab.md#installations-from-source) for the changes to take effect.
## Group Sync **(STARTER ONLY)**
## Group Sync **(PREMIUM SELF)**
If your LDAP supports the `memberof` property, when the user signs in for the
first time GitLab triggers a sync for groups the user should be a member of.
...
...
@@ -629,11 +629,11 @@ following.
To take advantage of group sync, group owners or maintainers need to [create one
or more LDAP group links](#adding-group-links).
### Adding group links **(STARTER ONLY)**
### Adding group links **(PREMIUM SELF)**
For information on adding group links via CNs and filters, refer to [the GitLab groups documentation](../../../user/group/index.md#manage-group-memberships-via-ldap).
### Administrator sync **(STARTER ONLY)**
### Administrator sync **(PREMIUM SELF)**
As an extension of group sync, you can automatically manage your global GitLab
administrators. Specify a group CN for `admin_group` and all members of the
...
...
@@ -677,7 +677,7 @@ group, as opposed to the full DN.
1.[Restart GitLab](../../restart_gitlab.md#installations-from-source) for the changes to take effect.
### Global group memberships lock **(STARTER ONLY)**
### Global group memberships lock **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1793) in GitLab 12.0.
...
...
@@ -696,7 +696,7 @@ To enable it you need to:
1. Navigate to **(admin)****Admin Area > Settings -> Visibility and access controls**.
1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
### Adjusting LDAP group sync schedule **(STARTER ONLY)**
### Adjusting LDAP group sync schedule **(PREMIUM SELF)**
By default, GitLab runs a group sync process every hour, on the hour.
The values shown are in cron format. If needed, you can use a
...
...
@@ -735,7 +735,7 @@ sync to run once every 2 hours at the top of the hour.
1.[Restart GitLab](../../restart_gitlab.md#installations-from-source) for the changes to take effect.
### External groups **(STARTER ONLY)**
### External groups **(PREMIUM SELF)**
Using the `external_groups` setting will allow you to mark all users belonging
to these groups as [external users](../../../user/permissions.md#external-users).
| `request_access_enabled` | boolean | no | Allow users to request member access. |
| `parent_id` | integer | no | The parent group ID for creating nested group. |
| `default_branch_protection` | integer | no | See [Options for `default_branch_protection`](#options-for-default_branch_protection). Default to the global level default branch protection setting. |
| `shared_runners_minutes_limit` | integer | no | **(STARTER ONLY)** Pipeline minutes quota for this group (included in plan). Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0` |
| `extra_shared_runners_minutes_limit` | integer | no | **(STARTER ONLY)** Extra pipeline minutes quota for this group (purchased in addition to the minutes included in the plan). |
| `shared_runners_minutes_limit` | integer | no | **(PREMIUM SELF)** Pipeline minutes quota for this group (included in plan). Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0` |
| `extra_shared_runners_minutes_limit` | integer | no | **(PREMIUM SELF)** Extra pipeline minutes quota for this group (purchased in addition to the minutes included in the plan). |
### Options for `default_branch_protection`
...
...
@@ -838,8 +838,8 @@ PUT /groups/:id
| `request_access_enabled` | boolean | no | Allow users to request member access. |
| `default_branch_protection` | integer | no | See [Options for `default_branch_protection`](#options-for-default_branch_protection). |
| `file_template_project_id` | integer | no | **(PREMIUM)** The ID of a project to load custom file templates from. |
| `shared_runners_minutes_limit` | integer | no | **(STARTER ONLY)** Pipeline minutes quota for this group (included in plan). Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0` |
| `extra_shared_runners_minutes_limit` | integer | no | **(STARTER ONLY)** Extra pipeline minutes quota for this group (purchased in addition to the minutes included in the plan). |
| `shared_runners_minutes_limit` | integer | no | **(PREMIUM SELF)** Pipeline minutes quota for this group (included in plan). Can be `nil` (default; inherit system default), `0` (unlimited) or `> 0` |
| `extra_shared_runners_minutes_limit` | integer | no | **(PREMIUM SELF)** Extra pipeline minutes quota for this group (purchased in addition to the minutes included in the plan). |
| `prevent_forking_outside_group` | boolean | no | **(PREMIUM)** When enabled, users can **not** fork projects from this group to external namespaces
| `shared_runners_setting` | string | no | See [Options for `shared_runners_setting`](#options-for-shared_runners_setting). Enable or disable shared runners for a group's subgroups and projects. |
@@ -187,7 +187,7 @@ The name of the attribute can be anything you like, but it must contain the grou
to which a user belongs. In order to tell GitLab where to find these groups, you need
to add a `groups_attribute:` element to your SAML settings.
### Required groups **(STARTER ONLY)**
### Required groups **(PREMIUM SELF)**
Your IdP passes Group Information to the SP (GitLab) in the SAML Response. You need to configure GitLab to identify:
...
...
@@ -213,7 +213,7 @@ Example:
}}
```
### External Groups **(STARTER ONLY)**
### External groups **(PREMIUM SELF)**
SAML login supports automatic identification on whether a user should be considered an [external](../user/permissions.md) user. This is based on the user's group membership in the SAML identity provider.
...
...
@@ -231,7 +231,7 @@ SAML login supports automatic identification on whether a user should be conside
}}
```
### Admin Groups **(STARTER ONLY)**
### Admin groups **(PREMIUM SELF)**
The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell
GitLab where to look for the groups in the SAML response, and which group(s) should be
...
...
@@ -251,7 +251,7 @@ considered admin users.
}}
```
### Auditor Groups **(STARTER ONLY)**
### Auditor groups **(PREMIUM SELF)**
> Introduced in [GitLab Starter](https://about.gitlab.com/pricing/) 11.4.
@@ -327,7 +327,7 @@ A group's **Details** page includes tabs for:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207164) in GitLab [Starter](https://about.gitlab.com/pricing/) 12.10 as
a [beta feature](https://about.gitlab.com/handbook/product/#beta)
The group details view also shows the number of the following items created in the last 90 days: **(STARTER)**
The group details view also shows the number of the following items created in the last 90 days: **(PREMIUM)**
- Merge requests.
- Issues.
...
...
@@ -389,7 +389,7 @@ To share a given group, for example, 'Frontend' with another group, for example,
All the members of the 'Engineering' group will have been added to 'Frontend'.
## Manage group memberships via LDAP **(STARTER ONLY)**
## Manage group memberships via LDAP **(PREMIUM SELF)**
Group syncing allows LDAP groups to be mapped to GitLab groups. This provides more control over per-group user management. To configure group syncing edit the `group_base`**DN** (`'OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'`). This **OU** contains all groups that will be associated with GitLab groups.
...
...
@@ -400,7 +400,7 @@ For more information on the administration of LDAP and group sync, refer to the
NOTE:
If an LDAP user is a group member when LDAP Synchronization is added, and they are not part of the LDAP group, they will be removed from the group.
### Creating group links via CN **(STARTER ONLY)**
### Creating group links via CN **(PREMIUM SELF)**
To create group links via CN:
...
...
@@ -428,7 +428,7 @@ To create group links via filter:
### Overriding user permissions **(STARTER ONLY)**
### Overriding user permissions **(PREMIUM SELF)**
In GitLab [8.15](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/822) and later, LDAP user permissions can now be manually overridden by an admin user. To override a user's permissions:
...
...
@@ -616,7 +616,7 @@ To enable this feature, navigate to the group settings page. Select
#### Member Lock **(STARTER)**
#### Member Lock **(PREMIUM)**
Member lock lets a group owner prevent any new project membership to all of the
projects within a group, allowing tighter control over project membership.
...
...
@@ -814,11 +814,11 @@ To enable prevent project forking:
-**Webhooks**: Configure [webhooks](../project/integrations/webhooks.md) for your group.
-**Kubernetes cluster integration**: Connect your GitLab group with [Kubernetes clusters](clusters/index.md).
in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
> - Code Owners for Merge Request approvals was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4418) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.9.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6916) in GitLab 11.3.
> - Code Owners for Merge Request approvals was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4418) in GitLab Premium 11.9.
## Introduction
...
...
@@ -18,7 +17,7 @@ to find out who should review or approve merge requests.
Additionally, if you have a question over a specific file or
code block, it may be difficult to know who to find the answer from.
GitLab Code Owners is a feature to define who owns specific
The GitLab Code Owners feature defines who owns specific
files or paths in a repository, allowing other users to understand
who is responsible for each file or path.
...
...
@@ -32,7 +31,7 @@ the process of finding the right reviewers and approvers for a given
merge request.
In larger organizations or popular open source projects, Code Owners
can also be useful to understand who to contact if you have
can help you understand who to contact if you have
a question that may not be related to code review or a merge request
approval.
...
...
@@ -49,12 +48,12 @@ You can choose to add the `CODEOWNERS` file in three places:
- Inside the `docs/` directory
The `CODEOWNERS` file is valid for the branch where it lives. For example, if you change the code owners
in a feature branch, they won't be valid in the main branch until the feature branch is merged.
in a feature branch, the changes aren't valid in the main branch until the feature branch is merged.
If you introduce new files to your repository and you want to identify the code owners for that file,
you have to update `CODEOWNERS` accordingly. If you update the code owners when you are adding the files (in the same
branch), GitLab will count the owners as soon as the branch is merged. If
you don't, you can do that later, but your new files will not belong to anyone until you update your
you must update `CODEOWNERS` accordingly. If you update the code owners when you are adding the files (in the same
branch), GitLab counts the owners as soon as the branch is merged. If
you don't, you can do that later, but your new files don't belong to anyone until you update your
`CODEOWNERS` file in the TARGET branch.
When a file matches multiple entries in the `CODEOWNERS` file,
...
...
@@ -73,29 +72,32 @@ The user that would show for `README.md` would be `@user2`.
## Approvals by Code Owners
Once you've added Code Owners to a project, you can configure it to
After you've added Code Owners to a project, you can configure it to
be used for merge request approvals:
- As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers).
- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
Developer or higher [permissions](../permissions.md) are required in order to
Developer or higher [permissions](../permissions.md) are required to
approve a merge request.
Once set, Code Owners are displayed in merge requests widgets:
After it's set, Code Owners are displayed in merge request widgets:
1. Use [the syntax of Code Owners files](code_owners.md#the-syntax-of-code-owners-files)
to specify the actual owners and granular permissions.
Using Code Owners in conjunction with [Protected Branches](protected_branches.md#protected-branches-approval-by-code-owners)
will prevent any user who is not specified in the `CODEOWNERS` file from pushing
prevents any user who is not specified in the `CODEOWNERS` file from pushing
changes for the specified files/paths, except those included in the
**Allowed to push** column. This allows for a more inclusive push strategy, as
administrators don't have to restrict developers from pushing directly to the
...
...
@@ -114,13 +116,13 @@ in the `.gitignore` file followed by one or more of:
- The `@name` of one or more groups that should be owners of the file.
- Lines starting with `#` are ignored.
The order in which the paths are defined is significant: the last pattern that
matches a given path will be used to find the code owners.
The path definition order is significant: the last pattern
matching a given path is used to find the code owners.
### Groups as Code Owners
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182) in GitLab Starter 12.1.
> - Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.0.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182) in GitLab 12.1.
> - Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0.
Groups and subgroups members are inherited as eligible Code Owners to a
project, as long as the hierarchy is respected.
...
...
@@ -131,7 +133,7 @@ suppose you have a project called "Project A" within the group and a
"Project B" within the subgroup.
The eligible Code Owners to Project B are both the members of the Group X and
the Subgroup Y. And the eligible Code Owners to the Project A are just the
the Subgroup Y. The eligible Code Owners to the Project A are just the
members of the Group X, given that Project A doesn't belong to the Subgroup Y:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12137) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2 behind a feature flag, enabled by default.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12137) in GitLab Premium 13.2 behind a feature flag, enabled by default.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42389) in GitLab 13.4.
Code Owner rules can be grouped into named sections. This allows for better
...
...
@@ -185,8 +187,8 @@ changes, to set their own independent patterns by specifying discrete sections i
teams can be added as reviewers.
Sections can be added to `CODEOWNERS` files as a new line with the name of the
section inside square brackets. Every entry following it is assigned to that
section. The following example would create 2 Code Owner rules for the "README
section inside square brackets. Every entry following is assigned to that
section. The following example would create two Code Owner rules for the "README
Owners" section:
```plaintext
...
...
@@ -196,7 +198,7 @@ internal/README.md @user2
```
Multiple sections can be used, even with matching file or directory patterns.
Reusing the same section name will group the results together under the same
Reusing the same section name groups the results together under the same
section, with the most specific rule or last matching pattern being used. For
example, consider the following entries in a `CODEOWNERS` file:
...
...
@@ -213,7 +215,7 @@ model/db @gl-database
README.md @gl-docs
```
This will result in 3 entries under the "Documentation" section header, and 2
This results in three entries under the "Documentation" section header, and two
entries under "Database". Case is not considered when combining sections, so in
this example, entries defined under the sections "Documentation" and
"DOCUMENTATION" would be combined into one, using the case of the first instance
...
...
@@ -227,9 +229,10 @@ the rules for "Groups" and "Documentation" sections:
#### Optional Code Owners Sections **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232995) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.8 behind a feature flag, enabled by default.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232995) in GitLab Premium 13.8 behind a feature flag, enabled by default.
When you want to make a certain section optional, you can do so by adding a code owners section prepended with the caret `^` character. Approvals from owners listed in the section will **not** be required. For example:
To make a certain section optional, add a code owners section prepended with the
caret `^` character. Approvals from owners listed in the section are **not** required. For example:
```plaintext
[Documentation]
...
...
@@ -242,13 +245,13 @@ When you want to make a certain section optional, you can do so by adding a code
*.go @root
```
The optional code owners section will be displayed in merge requests under the **Approval Rules** area:
The optional code owners section displays in merge requests under the **Approval Rules** area:
GitLab provides syntax highlighting on all files through the [Rouge](https://rubygems.org/gems/rouge) Ruby gem. It will try to guess what language to use based on the file extension, which most of the time is sufficient.
GitLab provides syntax highlighting on all files through the [Rouge](https://rubygems.org/gems/rouge) Ruby gem. It attempts to guess what language to use based on the file extension, which most of the time is sufficient.
NOTE:
The [Web IDE](web_ide/index.md) and [Snippets](../snippets.md) use [Monaco Editor](https://microsoft.github.io/monaco-editor/)
...
...
@@ -25,10 +25,10 @@ you can add the following to your `.gitattributes` file:
```
<!-- vale gitlab.Spelling = NO -->
When you check in and push that change, all `*.pl` files in your project will be highlighted as Prolog.
When you check in and push that change, all `*.pl` files in your project are highlighted as Prolog.
<!-- vale gitlab.Spelling = YES -->
The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used Ruby syntax, all you need is:
The paths here are Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used Ruby syntax, all you need is:
``` conf
/Nicefilegitlab-language=ruby
...
...
@@ -44,7 +44,8 @@ To disable highlighting entirely, use `gitlab-language=text`. Lots more fun shen
/other-filegitlab-language=text?token=Error
```
Please note that these configurations will only take effect when the `.gitattributes` file is in your default branch (usually `master`).
Please note that these configurations only take effect when the `.gitattributes`
file is in your default branch (usually `master`).
NOTE:
The Web IDE does not support `.gitattribute` files, but it's [planned for a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/22014).
-[Requirements](requirements/index.md): Requirements allow you to create criteria to check your products against. **(ULTIMATE)**
...
...
@@ -192,7 +192,7 @@ To delete a project, first navigate to the home page for that project.
1. Click **Delete project**
1. Confirm this action by typing in the expected text.
Projects in personal namespaces are deleted immediately on request. For information on delayed deletion of projects within a group, please see [Enabling delayed project removal](../group/index.md#enabling-delayed-project-removal).
Projects in personal namespaces are deleted immediately on request. For information on delayed deletion of projects in a group, please see [Enabling delayed project removal](../group/index.md#enabling-delayed-project-removal).
When enabled, all merge requests targeting these branches will require approval
When enabled, all merge requests targeting these branches require approval
by a Code Owner per matched rule before they can be merged.
Additionally, direct pushes to the protected branch are denied if a rule is matched.
...
...
@@ -224,26 +213,9 @@ for details about the pipelines security model.
## Changelog
**13.5**
-[Allow Deploy keys to push to protected branches once more](https://gitlab.com/gitlab-org/gitlab/-/issues/30769).
**11.9**
-[Allow protected branches to be created](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53361) by Developers (and users with higher permission levels) through the API and the user interface.
**9.2**
- Allow deletion of protected branches via the web interface ([issue #21393](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21393)).
**8.11**
- Allow creating protected branches that can't be pushed to ([merge request !5081](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5081)).
**8.10**
- Allow developers without push access to merge into a protected branch ([merge request !4892](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4892)).
- Allow specifying protected branches using wildcards ([merge request !4665](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4665)).
-**13.5**: [Allow Deploy keys to push to protected branches once more](https://gitlab.com/gitlab-org/gitlab/-/issues/30769).
-**11.9**: [Allow protected branches to be created](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53361)
by Developers (and users with higher permission levels) through the API and the user interface.
@@ -15,11 +15,13 @@ This feature evolved out of [protected branches](protected_branches.md)
## Overview
Protected tags will prevent anyone from updating or deleting the tag, and will prevent creation of matching tags based on the permissions you have selected. By default, anyone without Maintainer permission will be prevented from creating tags.
Protected tags prevent anyone from updating or deleting the tag, and prevent
creation of matching tags based on the permissions you have selected. By default,
anyone without Maintainer [permissions](../permissions.md) is prevented from creating tags.
## Configuring protected tags
To protect a tag, you need to have at least Maintainer permission level.
To protect a tag, you need to have at least Maintainer [permissions](../permissions.md).
1. Navigate to the project's **Settings > Repository**:
...
...
@@ -29,17 +31,18 @@ To protect a tag, you need to have at least Maintainer permission level.
Project access tokens are supported for self-managed instances on Core and above. They are also supported on GitLab.com Bronze and above (excluding [trial licenses](https://about.gitlab.com/free-trial/)).
Project access tokens are supported for self-managed instances on Free and above. They are also supported on GitLab SaaS Premium and above (excluding [trial licenses](https://about.gitlab.com/free-trial/)).
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2587) in GitLab 13.0.
> - [Became available on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/235765) in GitLab 13.5 for paid groups only.
