Merge branch 'tweak-security-release-mr-template' into 'master'

Clarify the correct milestone for security fixes in `master`

See merge request gitlab-org/gitlab!68182

.gitlab/issue_templates/Security developer workflow.md

@@ -29,6 +29,7 @@ After your merge request has been approved according to our [approval guidelines
 ## Backports
 
 - [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
+   * The 3 stable branches correspond to the versions in the title of the Security Release Tracking Issue.
    * At this point, it might be easy to squash the commits from the MR into one
    * You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
 - [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].

.gitlab/merge_request_templates/Security Release.md

@@ -14,7 +14,6 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 
 - [ ] **On "Related issues" section, write down the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
 - [ ] Merge request targets `master`, or a versioned stable branch (`X-Y-stable-ee`).
-- [ ] Milestone is set for the version this merge request applies to. A closed milestone can be assigned via [quick actions].
 - [ ] Title of this merge request is the same as for all backports.
 - [ ] A [CHANGELOG entry] has been included, with `Changelog` trailer set to `security`.
 - [ ] For the MR targeting `master`:
@@ -24,6 +23,7 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
     - Please see the security release [Code reviews and Approvals](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals) documentation for details on which AppSec team member to ping for approval.
     - Trigger the [`package-and-qa` build]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
 - [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`)
+  - [ ] Milestone is set to the version this backport applies to. A closed milestone can be assigned via [quick actions].
   - [ ] Ensure it's approved by a maintainer.
 
 **Note:** Reviewer/maintainer should not be a Release Manager

danger/metadata/Dangerfile

@@ -2,6 +2,8 @@
 
 # rubocop:disable Style/SignalException
 
+DEFAULT_BRANCH = 'master'
+
 THROUGHPUT_LABELS = [
   'Community contribution',
   'security',
@@ -29,12 +31,12 @@ end
 
 has_milestone = !gitlab.mr_json["milestone"].nil?
 
-unless has_milestone
+unless has_milestone || (helper.security_mr? && gitlab.branch_for_base == DEFAULT_BRANCH)
   warn "This merge request does not refer to an existing milestone.", sticky: false
 end
 
 has_pick_into_stable_label = gitlab.mr_labels.find { |label| label.start_with?('Pick into') }
 
-if gitlab.branch_for_base != "master" && !has_pick_into_stable_label && !helper.security_mr?
-  warn "Most of the time, merge requests should target `master`. Otherwise, please set the relevant `Pick into X.Y` label."
+if gitlab.branch_for_base != DEFAULT_BRANCH && !has_pick_into_stable_label && !helper.security_mr?
+  warn "Most of the time, merge requests should target `#{DEFAULT_BRANCH}`. Otherwise, please set the relevant `Pick into X.Y` label."
 end