Add latest changes from gitlab-org/gitlab@13-6-stable-eev13.6.0-rc42

4 files changed, 66 insertions, 41 deletions

diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 6cbe57bf926..17431195c3d 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -37,7 +37,7 @@ Report suspected security vulnerabilities in private to
 `support@gitlab.com`, also see the
 [disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/).
 
-DANGER: **Danger:**
+DANGER: **Warning:**
 Do **NOT** create publicly viewable issues for suspected security vulnerabilities.
 
 ## Code of conduct
@@ -146,7 +146,7 @@ Keep the following in mind when submitting merge requests:
   reviewers.
 - If the code quality is found to not meet GitLab’s standards, the merge request reviewer will
   provide guidance and refer the author to our:
-  - [Documentation](../documentation/styleguide.md) style guide.
+  - [Documentation](../documentation/styleguide/index.md) style guide.
   - Code style guides.
 - Sometimes style guides will be followed but the code will lack structural integrity, or the
   reviewer will have reservations about the code’s overall quality. When there is a reservation,
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index b7c05a369f0..99650c24661 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -90,25 +90,6 @@ explain what falls under each type label.
 
 The GitLab handbook documents [when something is a bug](https://about.gitlab.com/handbook/product/product-processes/#bug-issues) and [when it is a feature request](https://about.gitlab.com/handbook/product/product-processes/#feature-issues).
 
-### Facet labels
-
-Sometimes it's useful to refine the type of an issue. In those cases, you can
-add facet labels.
-
-Following is a non-exhaustive list of facet labels:
-
-- ~enhancement: This label can refine an issue that has the ~feature label.
-- ~"master:broken": This label can refine an issue that has the ~bug label.
-- ~"failure::flaky-test": This label can refine an issue that has the ~bug label.
-- ~"technical debt": This label can refine an issue that has the ~tooling label.
-- ~"static analysis": This label can refine an issue that has the ~tooling label.
-- ~"ci-build": This label can refine an issue that has the ~tooling label.
-- ~performance: A performance issue could describe a ~bug or a ~feature.
-- ~security: A security issue could describe a ~bug or a ~feature.
-- ~database: A database issue could describe a ~bug or a ~feature.
-- ~customer: This relates to an issue that was created by a customer, or that is of interest for a customer.
-- ~"UI text": Issues that add or modify any text within the UI such as user-assistance microcopy, button/menu labels, or error messages.
-
 ### Stage labels
 
 Stage labels specify which [stage](https://about.gitlab.com/handbook/product/product-categories/#hierarchy) the issue belongs to.
@@ -226,6 +207,13 @@ Examples of feature labels are `~wiki`, `~ldap`, `~api`, `~issues`, `~"merge req
 
 Feature labels are all-lowercase.
 
+### Facet labels
+
+To track additional information or context about created issues, developers may
+add _facet labels_. Facet labels are also sometimes used for issue prioritization
+or for measurements (such as time to close). An example of a facet label is the
+~customer label, which indicates customer interest.
+
 ### Department labels
 
 The current department labels are:
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 31f59ad875c..d5ffff7bfc8 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -123,24 +123,37 @@ document from the Kubernetes team also has some great points regarding this.
 
 ### Commit messages guidelines
 
-When writing commit messages, please follow the guidelines below:
+Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/):
 
-- The commit subject must contain at least 3 words.
-- The commit subject must not be longer than 72 characters.
+- The commit subject and body must be separated by a blank line.
 - The commit subject must start with a capital letter.
+- The commit subject must not be longer than 72 characters.
 - The commit subject must not end with a period.
-- The commit subject and body must be separated by a blank line.
 - The commit body must not contain more than 72 characters per line.
 - Commits that change 30 or more lines across at least 3 files must
   describe these changes in the commit body.
 - The commit subject or body must not contain Emojis.
 - Use issues and merge requests' full URLs instead of short references,
   as they are displayed as plain text outside of GitLab.
-- The merge request must not contain more than 10 commit messages.
+- The merge request should not contain more than 10 commit messages.
+- The commit subject should contain at least 3 words.
+
+**Important notes:**
+
+- If the guidelines are not met, the MR may not pass the [Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile).
+- Consider enabling [Squash and merge](../../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
+  if your merge request includes "Applied suggestion to X files" commits, so that Danger can ignore those.
+- The prefixes in the form of `[prefix]` and `prefix:` are allowed (they can be all lowercase, as long
+  as the message itself is capitalized). For instance, `danger: Improve Danger behavior` and
+  `[API] Improve the labels endpoint` are valid commit messages.
+
+#### Why these standards matter
+
+1. Consistent commit messages that follow these guidelines make the history more readable.
+1. Concise standard commit messages helps to identify breaking changes for a deployment or ~"master:broken" quicker when
+   reviewing commits between two points in time.
 
-If the guidelines are not met, the MR will not pass the
-[Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile).
-For more information see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
+#### Commit message template
 
 Example commit message template that can be used on your machine that embodies the above (guide for [how to apply template](https://codeinthehole.com/tips/a-useful-template-for-commit-messages/)):
 
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 773c1a771cd..fd3fe239110 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -15,25 +15,49 @@ settings automatically by default. If your editor/IDE does not automatically sup
 we suggest investigating to see if a plugin exists. For instance here is the
 [plugin for vim](https://github.com/editorconfig/editorconfig-vim).
 
-## Pre-commit static analysis
+## Pre-push static analysis
 
-You should install [`overcommit`](https://github.com/sds/overcommit) to automatically check for
-static analysis offenses before committing locally.
+We strongly recommend installing [Lefthook](https://github.com/Arkweid/lefthook) to automatically check
+for static analysis offenses before pushing your changes.
 
-After installing `overcommit`, run the following in your GitLab source directory:
+To install `lefthook`, run the following in your GitLab source directory:
 
 ```shell
-make -C tooling/overcommit
+# 1. Make sure to uninstall Overcommit first
+overcommit --uninstall
+
+# If using rbenv, at this point you may need to do: rbenv rehash
+
+# 2. Install lefthook...
+
+## With Homebrew (macOS)
+brew install Arkweid/lefthook/lefthook
+
+## Or with Go
+go get github.com/Arkweid/lefthook
+
+## Or with Rubygems
+gem install lefthook
+
+# 3. Install the Git hooks
+lefthook install -f
 ```
 
-Then before a commit is created, `overcommit` automatically checks for RuboCop (and other checks)
-offenses on every modified file.
+Before you push your changes, Lefthook then automatically run Danger checks, and other checks
+for changed files. This saves you time as you don't have to wait for the same errors to be detected
+by CI/CD.
+
+Lefthook relies on a pre-push hook to prevent commits that violate its ruleset.
+To override this behavior, pass the environment variable `LEFTHOOK=0`. That is,
+`LEFTHOOK=0 git push`.
 
-This saves you time as you don't have to wait for the same errors to be detected by CI/CD.
+You can also:
 
-`overcommit` relies on a pre-commit hook to prevent commits that violate its ruleset. To override
-this behavior, pass the `OVERCOMMIT_DISABLE` environment variable. For example,
-`OVERCOMMIT_DISABLE=1 git rebase master` to rebase while disabling the Git hook.
+- Define [local configuration](https://github.com/Arkweid/lefthook/blob/master/docs/full_guide.md#local-config).
+- Skip [checks per tag on the fly](https://github.com/Arkweid/lefthook/blob/master/docs/full_guide.md#skip-some-tags-on-the-fly).
+  For example, `LEFTHOOK_EXCLUDE=frontend git push origin`.
+- Run [hooks manually](https://github.com/Arkweid/lefthook/blob/master/docs/full_guide.md#run-githook-group-directly).
+  For example, `lefthook run pre-push`.
 
 ## Ruby, Rails, RSpec
 
@@ -100,7 +124,7 @@ We're following [Ciro Santilli's Markdown Style Guide](https://cirosantilli.com/
 
 ## Documentation
 
-See the dedicated [Documentation Style Guide](../documentation/styleguide.md).
+See the dedicated [Documentation Style Guide](../documentation/styleguide/index.md).
 
 ## Python