Add latest changes from gitlab-org/gitlab@master

doc/ci/directed_acyclic_graph/index.md

@@ -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).

doc/ci/multi_project_pipelines.md

@@ -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.

doc/ci/yaml/README.md

@@ -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.
 

doc/public_access/public_access.md

@@ -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

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -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

doc/user/group/index.md

@@ -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
 

doc/user/project/deploy_boards.md

@@ -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)
 

doc/user/project/protected_branches.md

@@ -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