Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
fb214ec6e0
commit
b75a1464a0
|
@ -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'
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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])
|
||||
|
||||
|
|
|
@ -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 } }
|
||||
|
||||
|
|
Loading…
Reference in New Issue