- Create two scopes, build and cookbooks
- Add some optional sections for reviewers who won't be maintainers, but
are good suggestions for reviewers
- Allow any maintainers to merge docs
- Makes it clearer the expectations regarding the manual jobs that need to
be executed.
- Makes it clearer what is the expectation regarding the GitLab.com
pipeline.
- Change Omnibus GitLab project files to use the new devops::systems
label instead of devops::enablement
Signed-off-by: Robert Marshall <rmarshall@gitlab.com>
- Explicitly call out that testing builds on dev requires
a manual push to trigger the pipelines in the merge
request template checklist
Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>
- When we review new configuration options, the merge request template
should ensure we ask questions around what are the expected values to
make sure it's covered in the review process.
Related https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5935
Signed-off-by: Robert Marshall <rmarshall@gitlab.com>
The field is called "tag_regex", not "tag_format". This lead to some
Omnibus releases not having a changelog, as the API would use the
incorrect starting point for the range of commits to include.
This allows us to handle the Omnibus tag format, which isn't compliant
with semantic versioning. We filter out CE tags as we don't need them to
determine a changelog commit range, as no changelog commits are
introduced between creating the CE and EE tags.
See https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1551 for
more information.
This adds support for specifying a custom merge request link for
changelogs, using the trailer "MR". While the value can technically be
both a link and a Markdown reference, I strongly suggest we use regular
links. Regular links are easier to work with from the terminal, and will
work across mirrors (unlike short references such as !123).
See https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1551 for
more information.
- Move the security harness instruction to the dev steps
- Mention that AppSec needs to to approve the master MR
- Add an item for dealing with MRs with less than 4 backports
- Clarify that removing .cveignore entries is not part of the security
process and cross-link to the documentation for how to handle it.
Signed-off-by: Robert Marshall <rmarshall@gitlab.com>
* Don't require things which Danger should be flagging on
* Be more specific about when dev.gitlab.org needs to be run
* Add note about title description
* Flesh out reviewer list more
- Make it clear who is responsible for closing the confidential issue
when following the Security process.
Signed-off-by: Robert Marshall <rmarshall@gitlab.com>
Omnibus is moving its security development from dev.gitlab.org to a
project in a private group, as first step, issue and merge request
templates are being updated to reflect this.
Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/692
Mayra Cabrera
Steve Abrams
Clemens Beck
DJ Mountney
João Alexandre Cunha
Andrew Patterson
Nailia Iskhakova
Evan Read
Mitchell Nielsen
Suzanne Selhorn
Achilleas Pipinellis
Amy Qualls
Robert Marshall
Dustin Collins
Marcel Amirault
Andrew Kelly
Balasankar 'Balu' C
Ben Prescott @bprescott_↙ ☺
Kenneth Chu
Ben Bodenmiller
Achilleas Pipinellis
Craig Norris
Yorick Peterse
Andreas Brandl
Ben Bodenmiller
Ian Baum