-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[GitHub CI] Add step to block PRs from forked repositories unless they have the right label #1627
Conversation
Will the "label" action re-kick-off the failed build? |
It should according to the doc:
https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events |
dfe1d94
to
39ceaf6
Compare
39ceaf6
to
4808f6a
Compare
4808f6a
to
61e32e6
Compare
🚫 CI failed with log |
35a53ac
to
ef0e70b
Compare
ef0e70b
to
19e8d76
Compare
@jparise This is ready for review if you have a minute! |
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.
Nice idea!
Thank you! |
In TextureGroup#1627 I introduced an approval step that is meant to block PRs from forked repos unless they're labeled as "CI approved" by a maintainer. Turned out it doesn't work. When a label is added, a pull_request event with "labeled" as its action is fired but GitHub CI didn't restart the workflow. My guess is it checked the PR's commit and branch and determined that nothing has changed. Here is what the doc says: "A workflow runs on a specific version of code in your repository, determined by the commit SHA and Git ref" (https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events). This diff removes the label check so all PRs are automatically built. Here are the current usage limits in case we run into them: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits
In #1627 I introduced an approval step that is meant to block PRs from forked repos unless they're labeled as "CI approved" by a maintainer. Turned out it doesn't work. When a label is added, a pull_request event with "labeled" as its action is fired but GitHub CI didn't restart the workflow. My guess is it checked the PR's commit and branch and determined that nothing has changed. Here is what the doc says: "A workflow runs on a specific version of code in your repository, determined by the commit SHA and Git ref" (https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events). This diff removes the label check so all PRs are automatically built. Here are the current usage limits in case we run into them: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits
…y have the right label (TextureGroup#1627) Block pull requests from forked repositories that aren't from, and aren't labeled by, a maintainer. Adding "CI approved" label will unblock them.
In TextureGroup#1627 I introduced an approval step that is meant to block PRs from forked repos unless they're labeled as "CI approved" by a maintainer. Turned out it doesn't work. When a label is added, a pull_request event with "labeled" as its action is fired but GitHub CI didn't restart the workflow. My guess is it checked the PR's commit and branch and determined that nothing has changed. Here is what the doc says: "A workflow runs on a specific version of code in your repository, determined by the commit SHA and Git ref" (https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events). This diff removes the label check so all PRs are automatically built. Here are the current usage limits in case we run into them: https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits
Block pull requests from forked repositories that aren't from, and aren't labeled by, a maintainer.