-
-
Notifications
You must be signed in to change notification settings - Fork 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
Run browser tests on forked PRs by a dedicated label #4616
Conversation
Signed-off-by: Outsider <outsideris@gmail.com>
Signed-off-by: Outsider <outsideris@gmail.com>
There shouldn't be any Your solution is awkward, but I don't see any alternative way either... You could remove the |
No, it shouldn't be triggered by forked PRs. I just mentioned
That's a good idea. I will try it. |
Signed-off-by: Outsider <outsideris@gmail.com>
I used Add Remove Label actions. It will remove And I will more test with real PRs after merging this because there are some limitations outside of this repository. |
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 have some small comments only, lgtm.
Signed-off-by: Outsider <outsideris@gmail.com>
fixed. I will merge this to test with real forked PRs. |
Description of the Change
It is the only way I found to run browser tests on forked PR.
After reviewing code of a forked PR, maintainers can attach a
run-browser-test
label.Maintainers should check there is no malicious code to steal our secrets or do something bad on our repository.
This
Browser Tests
workflow will run based on forked PRs with writing repo and access secrets permissions. So, it can be dangerous if the forked PR has malicious code.I've tested
pull_request_target
event.When users open a pull request,
push
,pull_reqeust
andpull_request_target
will be run automatically. Butpull_request_target: types: [labeled]
(in this caseBrowser Tests
) will not be run becauselabeled
type.If maintainers attach a label except
run-browser-test
label,Browser Tests
workflow will be triggered, but it skipped because the label is notrun-browser-test
. In the above screenshot,pull request safe run
workflow ispull_request_target
workflow withlabeled
type.When maintainers attach the
run-browser-test
label,Browser Tests
workflow will be triggered. In above screenshot, I tested it withsafe-to-run
label.After that, when author of the forked PR pushed new commits, only default workflows will. be run.
That means maintainers should remove and re-attache
run-browser-test
label to runBrowser Tests
again.And when the forked PR already has
run-browser-test
label,Browser Tests
workflow will be triggered if maintainers attach a new label exceptrun-browser-test
label. We have to be careful with this.Alternate Designs
We can use
workflow_dispatch
event.workflow_dispatch
is a workflow that we should trigger it manually with PR number.I think there are some cons.
Therefore, I think
pull_request_target
event withlabeled
type is better thanworkflow_dispatch
event.Why should this be in core?
All forked PRs failed because of browser tests.
Applicable issues
close #4553