-
Notifications
You must be signed in to change notification settings - Fork 645
Add GitHub workflow to check for PRs with merge-blocking labels #862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| contains(github.event.pull_request.labels.*.name, 'breaking change') | ||
| run: | | ||
| echo "This is a breaking change." | ||
| exit 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made these all steps instead of e.g. different jobs because it cluttered up the list of checks in the PR view, but I don't feel strongly about it if there's a better organization.
|
|
||
| jobs: | ||
| label_checks: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this always be spacetimedb-runner?
It seemed like that always forced the jobs onto a queue, even for these runs that don't require anything fancy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, generally the spacetimedb-runner is going to be much faster compared to the regular github ubuntu-latest runner, but for things like this its fine to just use the github runner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description of Changes
Added a GitHub workflow to check for PRs with a
Do not mergelabel, for ad-hoc PR blocking.Note: A repo admin must make this a merge-blocking check!
API and ABI breaking changes
No runtime changes.
Expected complexity level and risk
1