From b75a1464a09fec24e54bc4829b44b39a31df9c19 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Tue, 10 May 2022 03:09:35 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- ...0210715094458_releases_with_milestones.yml | 2 +- doc/ci/pipelines/settings.md | 21 ++++++++++++++++ doc/development/code_review.md | 24 ++++++++----------- lib/tasks/gitlab/update_templates.rake | 2 +- .../profiles/emails_controller_spec.rb | 6 ++++- 5 files changed, 38 insertions(+), 17 deletions(-) diff --git a/config/metrics/counts_28d/20210715094458_releases_with_milestones.yml b/config/metrics/counts_28d/20210715094458_releases_with_milestones.yml index 74f9406a133..d5656bcc80b 100644 --- a/config/metrics/counts_28d/20210715094458_releases_with_milestones.yml +++ b/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' diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index a1180064c21..d1dc66c3347 100644 --- a/doc/ci/pipelines/settings.md +++ b/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). + ### Test coverage examples diff --git a/doc/development/code_review.md b/doc/development/code_review.md index a9e74fc2be4..a296717151e 100644 --- a/doc/development/code_review.md +++ b/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 diff --git a/lib/tasks/gitlab/update_templates.rake b/lib/tasks/gitlab/update_templates.rake index 247897bed0b..07dd5ebeacb 100644 --- a/lib/tasks/gitlab/update_templates.rake +++ b/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 ', '--message', commit_message]) diff --git a/spec/controllers/profiles/emails_controller_spec.rb b/spec/controllers/profiles/emails_controller_spec.rb index e41ae406d13..b63db831462 100644 --- a/spec/controllers/profiles/emails_controller_spec.rb +++ b/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 } }