Commit da2b2972 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent e7c9b53c
......@@ -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.
......
......@@ -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
......
......@@ -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):
1. Check the checkbox beside the name of each hosting site.
1. Click **Save changes**.
![import sources](img/import_sources.png)
## 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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment