ROX-31146: Reduce spam of Konflux PRs, releasers can approve#2387
ROX-31146: Reduce spam of Konflux PRs, releasers can approve#2387msugakov merged 4 commits intomasterstackrox/scanner:masterfrom misha/ROX-31146-reduce-mintmaker-emailsstackrox/scanner:misha/ROX-31146-reduce-mintmaker-emailsCopy head branch name to clipboard
Conversation
| # At the same time, we want to be notified when humans, not the bot, request reviews (through CODEOWNERS) for the | ||
| # Konflux-related files. This job invites `konflux-maintainers` team for review for such cases. | ||
| if: | | ||
| github.event.requested_team.name == 'rhtap-maintainers' && |
There was a problem hiding this comment.
| github.event.requested_team.name == 'rhtap-maintainers' && | |
| github.event.requested_team.name == 'konflux-no-notifications' && |
There was a problem hiding this comment.
I felt -no-email is shorter than -no-notifications while means almost the same (notifications inbox in GitHub is cool but I'm not used to it).
b7bac31 to
b122c37
Compare
konflux-maintainers|
@msugakov: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
.github/CODEOWNERS
Outdated
| # This will automatically assign a team / people as reviewers for PRs based on the files changed within the PR. | ||
|
|
||
| * @stackrox/scanner | ||
| * @stackrox/scanner @stackrox/release-mgmt-no-email |
There was a problem hiding this comment.
This will assign @stackrox/release-mgmt-no-email as a required reviewer on every PR - this intentional?
There was a problem hiding this comment.
Good point. Actually, do we need this to happen @tommartensen ? To put it differently, at some point I felt it's sensible to have @stackrox/release-mgmt-no-email for any Scanner PRs, intending the ones against the release branches. Now, when I think of this, we have MintMaker PRs covered by the rules below, and I can't think of any other cases when the release engineers would need this.
This reminds me of the discussion that we had in that thread but did not wrap up.
There was a problem hiding this comment.
We don't need it now.
In my suggestion I added it as intended for release branches. It could be helpful there to progress the release without waiting on scanner team (though scanner team runs their own releases today, so we still rely on them anyways).
As discussed in this thread this should address the problem of excessive emails from MintMaker and give release engineers permissions to approve MintMaker PRs in a way that they can also merge them.
Validation
I tested a similar workflow on this repo fork in this PR https://github.com/stackrox/mishas-operator-index-fork/pull/2 - feel free to take it over and play with it.
Example workflow run: https://github.com/stackrox/mishas-operator-index-fork/actions/runs/19261803985/job/55068116863?pr=2.
Post-merge
My next steps after merging this PR would be these: