Add latest changes from gitlab-org/gitlab@master

4 files changed, 19 insertions, 21 deletions

diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index 136e3c255de..dae0dae8395 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -294,9 +294,11 @@ This log records:
 
 - Information whenever [Rack Attack] registers an abusive request.
 - Requests over the [Rate Limit] on raw endpoints.
+- [Protected paths] abusive requests.
 
 NOTE: **Note:**
-From [%12.1](https://gitlab.com/gitlab-org/gitlab-foss/issues/62756), user id and username are available on this log.
+From [%12.1](https://gitlab.com/gitlab-org/gitlab-foss/issues/62756), user id and username are also
+recorded on this log, if available.
 
 ## `graphql_json.log`
 
@@ -341,10 +343,6 @@ will be generated in `/var/log/gitlab/gitlab-rails/web_exporter.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/web_exporter.log` for
 installations from source.
 
-[repocheck]: repository_checks.md
-[Rack Attack]: ../security/rack_attack.md
-[Rate Limit]: ../user/admin_area/settings/rate_limits_on_raw_endpoints.md
-
 ## `database_load_balancing.log` **(PREMIUM ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/15442) in GitLab 12.3.
@@ -354,3 +352,8 @@ It is stored at:
 
 - `/var/log/gitlab/gitlab-rails/database_load_balancing.log` for Omnibus GitLab packages.
 - `/home/git/gitlab/log/database_load_balancing.log` for installations from source.
+
+[repocheck]: repository_checks.md
+[Rack Attack]: ../security/rack_attack.md
+[Rate Limit]: ../user/admin_area/settings/rate_limits_on_raw_endpoints.md
+[Protected paths]: ../user/admin_area/settings/protected_paths.md
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 6f096c59c5c..88f5fd2cdc2 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -107,7 +107,7 @@ The following table lists available parameters for jobs:
 | [`environment`](#environment)                      | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, and `environment:action`.                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | [`cache`](#cache)                                  | List of files that should be cached between subsequent runs. Also available: `cache:paths`, `cache:key`, `cache:untracked`, and `cache:policy`.                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | [`artifacts`](#artifacts)                          | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, `artifacts:reports`, and `artifacts:reports:junit`.<br><br>In GitLab [Enterprise Edition](https://about.gitlab.com/pricing/), these are available: `artifacts:reports:codequality`, `artifacts:reports:sast`, `artifacts:reports:dependency_scanning`, `artifacts:reports:container_scanning`, `artifacts:reports:dast`, `artifacts:reports:license_management`, `artifacts:reports:performance` and `artifacts:reports:metrics`. |
-| [`dependencies`](#dependencies)                    | Other jobs that a job depends on so that you can pass artifacts between them.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| [`dependencies`](#dependencies)                    | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | [`coverage`](#coverage)                            | Code coverage settings for a given job.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | [`retry`](#retry)                                  | When and how many times a job can be auto-retried in case of a failure.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | [`timeout`](#timeout)                              | Define a custom job-level timeout that takes precedence over the project-wide setting.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
@@ -782,6 +782,8 @@ In this example, a job either set to:
 
 #### `rules:exists`
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/16574) in GitLab 12.4.
+
 `exists` accepts an array of paths and will match if any of these paths exist
 as files in the repository.
 
@@ -1455,7 +1457,7 @@ be available for download in the GitLab UI.
 You can only use paths that are within the local working copy.
 Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
 
-To pass artifacts between different jobs, see [dependencies](#dependencies).
+To restrict which jobs a specific job will fetch artifacts from, see [dependencies](#dependencies).
 
 Send all files in `binaries` and `.config`:
 
@@ -1799,10 +1801,9 @@ be automatically shown in merge requests.
 
 > Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
 
-This feature should be used in conjunction with [`artifacts`](#artifacts) and
-allows you to define the artifacts to pass between different jobs.
-
-Note that `artifacts` from all previous [stages](#stages) are passed by default.
+By default, all [`artifacts`](#artifacts) from all previous [stages](#stages)
+are passed, but you can use the `dependencies` parameter to define a limited
+list of jobs (or no jobs) to fetch artifacts from.
 
 To use this feature, define `dependencies` in context of the job and pass
 a list of all previous jobs from which the artifacts should be downloaded.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 31a5111132b..421b70bd2db 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -256,18 +256,12 @@ Since [unblocking others is always a top priority](https://about.gitlab.com/hand
 reviewers are expected to review assigned merge requests in a timely manner,
 even when this may negatively impact their other tasks and priorities.
 Doing so allows everyone involved in the merge request to iterate faster as the
-context is fresh in memory, improves contributors' experiences significantly,
-and gives authors more time to address feedback and iterate on their work before
-the [feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd).
+context is fresh in memory, improves contributors' experiences significantly.
 
 A turnaround time of two working days is usually acceptable, since engineers
 will typically have other things to work on while they're waiting for review,
 but don't hesitate to ask the author if it's unclear what time frame would be
-acceptable, how urgent the review is, or how significant the blockage. Authors
-are also encouraged to provide this information up-front to reviewers, but are
-expected to be mindful of the [guidelines on when to ask for review on MRs that
-are intended to go in before the feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#between-the-1st-and-the-7th),
-and realistic in their expectations if these were not followed.
+acceptable, how urgent the review is, or how significant the blockage.
 
 If you don't think you'll be able to review a merge request within a reasonable
 time frame, let the author know as soon as possible and try to help them find
diff --git a/doc/development/documentation/feature-change-workflow.md b/doc/development/documentation/feature-change-workflow.md
index 2b8a9ea6e1c..9e42d25d53a 100644
--- a/doc/development/documentation/feature-change-workflow.md
+++ b/doc/development/documentation/feature-change-workflow.md
@@ -7,7 +7,7 @@ description: How to add docs for new or enhanced GitLab features.
 At GitLab, developers contribute new or updated documentation along with their code, but product managers and technical writers also have essential roles in the process.
 
 - **Developers**: Author/update documentation in the same MR as their code, and
-  merge it by the feature freeze for the assigned milestone. Request technical writer
+  merge it in the assigned milestone. Request technical writer
   assistance if needed. Other developers typically act as reviewers.
 - **Product Managers** (PMs): In the issue for all new and enhanced features,
   confirm the documentation requirements, plus the mentioned feature description
@@ -40,7 +40,7 @@ interact with GitLab.
 NOTE: **Note:**
 When revamping documentation, if unrelated to the feature change, this should be submitted
 in its own MR (using the [documentation improvement workflow](improvement-workflow.md))
-so that we can ensure the more time-sensitive doc updates are merged with code by the freeze.
+so that we can ensure the more time-sensitive doc updates are merged sooner.
 
 ## Documentation requirements in feature issues