Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
e7c9b53c76
commit
da2b297213
|
@ -73,4 +73,4 @@ A directed acyclic graph is a complicated feature, and as of the initial MVC the
|
|||
are certain use cases that you may need to work around. For more information:
|
||||
|
||||
- [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations).
|
||||
- Related epic [#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).
|
||||
- Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716).
|
||||
|
|
|
@ -115,9 +115,11 @@ staging:
|
|||
branch: stable-11-2
|
||||
```
|
||||
|
||||
Use a `project` keyword to specify full path to a downstream project. Use
|
||||
a `branch` keyword to specify a branch name. Variable expansion is supported in
|
||||
the `branch` property.
|
||||
Use:
|
||||
|
||||
- The `project` keyword to specify the full path to a downstream project.
|
||||
- The `branch` keyword to specify the name of a branch in the project specified by `project`.
|
||||
Variable expansion is supported.
|
||||
|
||||
GitLab will use a commit that is currently on the HEAD of the branch when
|
||||
creating a downstream pipeline.
|
||||
|
|
|
@ -1897,14 +1897,14 @@ This example creates three paths of execution:
|
|||
- For self-managed instances, the limit is:
|
||||
- Five by default (`ci_dag_limit_needs` feature flag is enabled).
|
||||
- 50 if the `ci_dag_limit_needs` feature flag is disabled.
|
||||
- It is impossible for now to have `needs: []` (empty needs),
|
||||
the job always needs to depend on something, unless this is the job
|
||||
in the first stage (see [issue #65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
|
||||
- It is impossible for now to have `needs: []` (empty needs), the job always needs to
|
||||
depend on something, unless this is the job in the first stage. However, support for
|
||||
an empty needs array [is planned](https://gitlab.com/gitlab-org/gitlab/issues/30631).
|
||||
- If `needs:` refers to a job that is marked as `parallel:`.
|
||||
the current job will depend on all parallel jobs created.
|
||||
- `needs:` is similar to `dependencies:` in that it needs to use jobs from
|
||||
prior stages, meaning it is impossible to create circular
|
||||
dependencies or depend on jobs in the current stage (see [issue #65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
|
||||
- `needs:` is similar to `dependencies:` in that it needs to use jobs from prior stages,
|
||||
meaning it is impossible to create circular dependencies. Depending on jobs in the
|
||||
current stage is not possible either, but support [is planned](https://gitlab.com/gitlab-org/gitlab/issues/30632).
|
||||
- Related to the above, stages must be explicitly defined for all jobs
|
||||
that have the keyword `needs:` or are referred to by one.
|
||||
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 18 KiB |
|
@ -4,7 +4,7 @@ type: reference
|
|||
|
||||
# Public access
|
||||
|
||||
GitLab allows [Owners](../user/permissions.md) to set a projects' visibility as **public**, **internal**
|
||||
GitLab allows [Owners](../user/permissions.md) to set a project's visibility as **public**, **internal**,
|
||||
or **private**. These visibility levels affect who can see the project in the
|
||||
public access directory (`/public` under your GitLab instance), like at <https://gitlab.com/public>
|
||||
|
||||
|
@ -12,7 +12,7 @@ public access directory (`/public` under your GitLab instance), like at <https:/
|
|||
|
||||
### Public projects
|
||||
|
||||
Public projects can be cloned **without any** authentication over https.
|
||||
Public projects can be cloned **without any** authentication over HTTPS.
|
||||
|
||||
They will be listed in the public access directory (`/public`) for all users.
|
||||
|
||||
|
@ -43,8 +43,8 @@ They will appear in the public access directory (`/public`) for project members
|
|||
|
||||
### How to change project visibility
|
||||
|
||||
1. Go to your project's **Settings**
|
||||
1. Change "Visibility Level" to either Public, Internal or Private
|
||||
1. Go to your project's **Settings**.
|
||||
1. Change **Visibility Level** to either Public, Internal, or Private.
|
||||
|
||||
## Visibility of groups
|
||||
|
||||
|
@ -71,15 +71,12 @@ If the public level is restricted, user profiles are only visible to logged in u
|
|||
|
||||
## Restricting the use of public or internal projects
|
||||
|
||||
In the Admin area under **Settings** (`/admin/application_settings`), you can
|
||||
restrict the use of visibility levels for users when they create a project or a
|
||||
snippet:
|
||||
|
||||
![Restrict visibility levels](img/restrict_visibility_levels.png)
|
||||
|
||||
This is useful to prevent people exposing their repositories to public
|
||||
You can restrict the use of visibility levels for users when they create a project or a
|
||||
snippet. This is useful to prevent users from publicly exposing their repositories
|
||||
by accident. The restricted visibility settings do not apply to admin users.
|
||||
|
||||
For details, see [Restricted visibility levels](../user/admin_area/settings/visibility_and_access_controls.md#restricted-visibility-levels).
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 3.7 KiB |
Binary file not shown.
Before Width: | Height: | Size: 5.8 KiB |
|
@ -4,15 +4,7 @@ type: reference
|
|||
|
||||
# Visibility and access controls **(CORE ONLY)**
|
||||
|
||||
GitLab allows administrators to:
|
||||
|
||||
- Control access and visibility to GitLab resources including branches and projects.
|
||||
- Select from which hosting sites code can be imported into GitLab.
|
||||
- Select the protocols permitted to access GitLab.
|
||||
- Enable or disable repository mirroring.
|
||||
- Prevent non-administrators from deleting projects
|
||||
([introduced](https://gitlab.com/gitlab-org/gitlab/issues/5615) in GitLab 12.0).
|
||||
**(PREMIUM ONLY)**
|
||||
GitLab allows administrators to enforce specific controls.
|
||||
|
||||
To access the visibility and access control options:
|
||||
|
||||
|
@ -20,29 +12,111 @@ To access the visibility and access control options:
|
|||
1. Go to **Admin Area > Settings > General**.
|
||||
1. Expand the **Visibility and access controls** section.
|
||||
|
||||
## Default branch protection
|
||||
|
||||
Branch protection specifies which roles can push to branches and which roles can delete
|
||||
branches.
|
||||
|
||||
To change the default branch protection:
|
||||
|
||||
1. Select the desired option.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details, see [Protected branches](../../project/protected_branches.md).
|
||||
|
||||
## Default project creation protection
|
||||
|
||||
Project creation protection specifies which roles can create projects.
|
||||
|
||||
To change the default project creation protection:
|
||||
|
||||
1. Select the desired option.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level).
|
||||
|
||||
## Default project deletion protection
|
||||
|
||||
By default, a project can be deleted by anyone with the **Owner** role, either at the project or
|
||||
group level.
|
||||
|
||||
To ensure only admin users can delete projects:
|
||||
|
||||
1. Check the **Default project deletion protection** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
## Default project visibility
|
||||
|
||||
To set the default visibility levels for new projects:
|
||||
|
||||
1. Select the desired default project visibility.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details on project visibility, see [Public access](../../../public_access/public_access.md).
|
||||
|
||||
## Default snippet visibility
|
||||
|
||||
To set the default visibility levels for new snippets:
|
||||
|
||||
1. Select the desired default snippet visibility.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details on snippet visibility, see [Public access](../../../public_access/public_access.md).
|
||||
|
||||
## Default group visibility
|
||||
|
||||
To set the default visibility levels for new groups:
|
||||
|
||||
1. Select the desired default group visibility.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details on group visibility, see [Public access](../../../public_access/public_access.md).
|
||||
|
||||
## Restricted visibility levels
|
||||
|
||||
To set the available visibility levels for new projects and snippets:
|
||||
|
||||
1. Check the desired visibility levels.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details on project visibility, see [Public access](../../../public_access/public_access.md).
|
||||
|
||||
## Import sources
|
||||
|
||||
Choose from which hosting sites users can
|
||||
[import their projects](../../project/import/index.md).
|
||||
To specify from which hosting sites users can [import their projects](../../project/import/index.md):
|
||||
|
||||
![import sources](img/import_sources.png)
|
||||
1. Check the checkbox beside the name of each hosting site.
|
||||
1. Click **Save changes**.
|
||||
|
||||
## Project export
|
||||
|
||||
To enable project export:
|
||||
|
||||
1. Check the **Project export enabled** checkbox.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details, see [Exporting a project and its data](../../../user/project/settings/import_export.md#exporting-a-project-and-its-data).
|
||||
|
||||
## Enabled Git access protocols
|
||||
|
||||
> [Introduced][ce-4696] in GitLab 8.10.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4696) in GitLab 8.10.
|
||||
|
||||
With GitLab's access restrictions, you can select with which protocols users can communicate with
|
||||
GitLab.
|
||||
|
||||
From the **Enabled Git access protocols** dropdown, select one of the following:
|
||||
Disabling an access protocol does not block access to the server itself via those ports. The ports
|
||||
used for the protocol, SSH or HTTP, will still be accessible. The GitLab restrictions apply at the
|
||||
application level.
|
||||
|
||||
- Both SSH and HTTP(S)
|
||||
- Only SSH
|
||||
- Only HTTP(s)
|
||||
To specify the enabled Git access protocols:
|
||||
|
||||
![Settings Overview](img/access_restrictions.png)
|
||||
1. Select the desired Git access protocols from the dropdown:
|
||||
- Both SSH and HTTP(S)
|
||||
- Only SSH
|
||||
- Only HTTP(S)
|
||||
1. Click **Save changes**.
|
||||
|
||||
When both SSH and HTTP(S) are enabled, your users can choose either protocol.
|
||||
When both SSH and HTTP(S) are enabled, users can choose either protocol.
|
||||
|
||||
When only one protocol is enabled:
|
||||
|
||||
|
@ -57,18 +131,24 @@ On top of these UI restrictions, GitLab will deny all Git actions on the protoco
|
|||
not selected.
|
||||
|
||||
CAUTION: **Important:**
|
||||
Starting with [GitLab 10.7][ce-18021], HTTP(s) protocol will be allowed for
|
||||
Git clone/fetch requests done by GitLab Runner from CI/CD Jobs, even if
|
||||
_Only SSH_ was selected.
|
||||
Starting with [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18021),
|
||||
HTTP(S) protocol will be allowed for Git clone or fetch requests done by GitLab Runner
|
||||
from CI/CD jobs, even if _Only SSH_ was selected.
|
||||
|
||||
> **Note:** Please keep in mind that disabling an access protocol does not actually
|
||||
block access to the server itself. The ports used for the protocol, be it SSH or
|
||||
HTTP, will still be accessible. What GitLab does is restrict access on the
|
||||
application level.
|
||||
## RSA, DSA, ECDSA, ED25519 SSH keys
|
||||
|
||||
These options specify the permitted types and lengths for SSH keys.
|
||||
|
||||
To specify a restriction for each key type:
|
||||
|
||||
1. Select the desired option from the dropdown.
|
||||
1. Click **Save changes**.
|
||||
|
||||
For more details, see [SSH key restrictions](../../../security/ssh_keys_restrictions.md).
|
||||
|
||||
## Allow mirrors to be set up for projects
|
||||
|
||||
> [Introduced][ee-3586] in GitLab 10.3.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3586) in GitLab 10.3.
|
||||
|
||||
This option is enabled by default. By disabling it, both pull and push mirroring will no longer
|
||||
work in every repository and can only be re-enabled by an admin on a per-project basis.
|
||||
|
@ -86,7 +166,3 @@ 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-4696]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4696
|
||||
[ce-18021]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/18021
|
||||
[ee-3586]: https://gitlab.com/gitlab-org/gitlab/merge_requests/3586
|
||||
|
|
|
@ -182,14 +182,17 @@ There are two different ways to add a new project to a group:
|
|||
> Brought to [GitLab Starter][ee] in 10.7.
|
||||
> [Moved](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25975) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
|
||||
|
||||
Group owners and administrators can allow users with the
|
||||
Developer role to create projects under groups.
|
||||
By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group.
|
||||
|
||||
By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group. You can change this setting for a specific group within the group settings, or
|
||||
you can set this option globally in the Admin area
|
||||
at **Settings > General > Visibility and access controls** (you must be a GitLab administrator).
|
||||
To change this setting for a specific group:
|
||||
|
||||
Available settings are `No one`, `Maintainers`, or `Developers + Maintainers`.
|
||||
1. Go to the group's page.
|
||||
1. Go to **Settings > General**.
|
||||
1. Expand the **Permissions, LFS, 2FA** section.
|
||||
1. Select the desired option in the **Allowed to create projects** dropdown list.
|
||||
1. Click **Save changes**.
|
||||
|
||||
To change this setting globally, see [Default project creation protection](../admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection).
|
||||
|
||||
## Transfer projects into groups
|
||||
|
||||
|
|
|
@ -91,7 +91,8 @@ To display the Deploy Boards for a specific [environment] you should:
|
|||
Matching based on the Kubernetes `app` label was removed in [GitLab
|
||||
12.1](https://gitlab.com/gitlab-org/gitlab/merge_requests/14020).
|
||||
To migrate, please apply the required annotations (see above) and
|
||||
re-deploy your application.
|
||||
re-deploy your application. If you are using Auto DevOps, this will
|
||||
be done automatically and no action is necessary.
|
||||
|
||||
![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
|
||||
|
||||
|
|
|
@ -23,6 +23,8 @@ A GitLab admin is allowed to push to the protected branches.
|
|||
|
||||
See the [Changelog](#changelog) section for changes over time.
|
||||
|
||||
The default branch protection level is set in the [Admin Area](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection).
|
||||
|
||||
## Configuring protected branches
|
||||
|
||||
To protect a branch, you need to have at least Maintainer permission level. Note
|
||||
|
|
Loading…
Reference in New Issue