Add latest changes from gitlab-org/gitlab@master

config/metrics/counts_28d/20210715094458_releases_with_milestones.yml

@@ -1,7 +1,7 @@
 ---
 key_path: usage_activity_by_stage_monthly.release.releases_with_milestones
 description: Unique users creating releases with milestones associated
-performance_indicator_type: [smau]
+performance_indicator_type: []
 product_section: ops
 product_stage: release
 product_group: 'group::release'

doc/ci/pipelines/settings.md

@@ -232,6 +232,27 @@ using the [`coverage`](../yaml/index.md#coverage) keyword.
 This feature is in its end-of-life process. It was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/17633)
 in GitLab 14.8. The feature is [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/17633) in GitLab 15.0.
 
+To migrate from project settings to `coverage` keyword settings, add the former project setting to a CI/CD job with the `coverage` keyword. For
+example:
+
+- A Go test coverage project setting:  `coverage: \d+.\d+% of statements`.
+- A CI/CD job with `coverage` keyword setting:
+
+  ```yaml
+  unit-test:
+    stage: test
+    coverage: '/coverage: \d+.\d+% of statements/'
+    script:
+      - go test -cover
+  ```
+
+The `.gitlab-ci.yml` job [`coverage`](../yaml/index.md#coverage) keyword must:
+
+- Be a regular expression starts and ends with the `/` character.
+- Be defined as single-quoted string.
+
+You can verify correct syntax using the [pipeline editor](../pipeline_editor/index.md).
+
 <!-- end_remove -->
 
 ### Test coverage examples

doc/development/code_review.md

@@ -259,7 +259,7 @@ Avoid:
   [_explain why, not what_](https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/).
 - Requesting maintainer reviews of merge requests with failed tests. If the tests are failing and you have to request a review, ensure you leave a comment with an explanation.
 - Excessively mentioning maintainers through email or Slack (if the maintainer is reachable
-through Slack). If you can't add a reviewer for a merge request, it's acceptable to `@` mention a maintainer in a comment. In all other cases, it's sufficient to add a reviewer or [request their attention](../user/project/merge_requests/index.md#request-attention-to-a-merge-request) if they're already a reviewer.
+through Slack). If you can't add a reviewer for a merge request, `@` mentioning a maintainer in a comment is acceptable and in all other cases adding a reviewer is sufficient.
 
 This saves reviewers time and helps authors catch mistakes earlier.
 
@@ -269,8 +269,10 @@ This saves reviewers time and helps authors catch mistakes earlier.
 that it meets all requirements, you should:
 
 - Click the Approve button.
-- Request a review from a maintainer or [request their attention](../user/project/merge_requests/index.md#request-attention-to-a-merge-request) if they're already a reviewer. Default to requests for a maintainer with [domain expertise](#domain-experts),
+- `@` mention the author to generate a to-do notification, and advise them that their merge request has been reviewed and approved.
+- Request a review from a maintainer. Default to requests for a maintainer with [domain expertise](#domain-experts),
 however, if one isn't available or you think the merge request doesn't need a review by a [domain expert](#domain-experts), feel free to follow the [Reviewer roulette](#reviewer-roulette) suggestion.
+- Remove yourself as a reviewer.
 
 ### The responsibility of the maintainer
 
@@ -298,7 +300,7 @@ If a developer who happens to also be a maintainer was involved in a merge reque
 as a reviewer, it is recommended that they are not also picked as the maintainer to ultimately approve and merge it.
 
 Maintainers should check before merging if the merge request is approved by the
-required approvers. If still awaiting further approvals from others, explain that in a comment and [request attention](../user/project/merge_requests/index.md#request-attention-to-a-merge-request) from other reviewers as appropriate. Do not remove yourself as a reviewer.
+required approvers. If still awaiting further approvals from others, remove yourself as a reviewer then `@` mention the author and explain why in a comment. Stay as reviewer if you're merging the code.
 
 Maintainers must check before merging if the merge request is introducing new
 vulnerabilities, by inspecting the list in the merge request
@@ -320,20 +322,14 @@ After merging, a maintainer should stay as the reviewer listed on the merge requ
 
 ### Dogfooding the Reviewers feature
 
-Replaced with [dogfooding the attention request feature](#dogfooding-the-attention-request-feature).
-
-### Dogfooding the attention request feature
-
-In March of 2022, an updated process was put in place aimed at efficiently and consistently dogfooding the
-[attention requests feature](../user/project/merge_requests/index.md#request-attention-to-a-merge-request) under `Merge requests` -> `Need your attention`. This replaces previous guidance on [dogfooding the reviewers feature](#dogfooding-the-reviewers-feature).
+On March 18th 2021, an updated process was put in place aimed at efficiently and consistently dogfooding the Reviewers feature.
 
 Here is a summary of the changes, also reflected in this section above.
 
-- Merge request authors and DRIs stay as assignees
-- Assignees request a review from reviewer(s) when they are expected to review
-- Reviewers stay assigned for the entire duration of the merge request
-- Reviewers request attention from the assignee or other reviewer(s) after they've done reviewing, depending on who needs to take action
-- Assignees request attention from the reviewer(s) when changes are made
+- Merge request authors and DRIs stay as Assignees
+- Authors request a review from Reviewers when they are expected to review
+- Reviewers remove themselves after they're done reviewing/approving
+- The last approver stays as Reviewer upon merging
 
 ## Best practices
 

lib/tasks/gitlab/update_templates.rake

@@ -79,7 +79,7 @@ namespace :gitlab do
           Gitlab::TaskHelpers.run_command!(['tar', 'xf', 'archive.tar.gz'])
           extracted_project_basename = Dir['*/'].first
           Dir.chdir(extracted_project_basename) do
-            Gitlab::TaskHelpers.run_command!(%w(git init))
+            Gitlab::TaskHelpers.run_command!(%w(git init --initial-branch=master))
             Gitlab::TaskHelpers.run_command!(%w(git add .))
             Gitlab::TaskHelpers.run_command!(['git', 'commit', '--author', 'GitLab <root@localhost>', '--message', commit_message])
 

spec/controllers/profiles/emails_controller_spec.rb

@@ -62,7 +62,11 @@ RSpec.describe Profiles::EmailsController do
   end
 
   describe '#resend_confirmation_instructions' do
-    let_it_be(:email) { create(:email, user: user) }
+    let_it_be(:email) do
+      travel_to(5.minutes.ago) do
+        create(:email, user: user)
+      end
+    end
 
     let(:params) { { id: email.id } }