Support workflow_run
nemchik opened this issue · 7 comments
Is your feature request related to a problem? Please describe.
The current recommend setup is to run on a schedule. This can mean things get merged before they would get labeled if development is moving fast enough.
Describe the solution you'd like
Supporting workflow_run events means this workflow can be triggered when another workflow is triggered. So you would setup a pull request trigger workflow that this workflow would watch for. When the trigger runs (when a pull request is opened) this workflow would run. Basically triggered instead of scheduled
Describe alternatives you've considered
I've been trying everything under the sun to find a way to have pull request labeled on the spot.
Additional context
https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run
https://github.com/GhostWriters/DockSTARTer/runs/960569424?check_suite_focus=true
Hi @nemchik thanks for opening an issue!
A little background on why the pr-labeler job is a cron job instead of a more typical triggered action
PR's made from forks do not have permission on the base repo. This is primarily a security measure so that someone can't create a PR with some malicious action code that will run on the "PR opened" event. This issue in the actions/labeler repo illustrates this well and I think it makes sense. You don't want to expose your repository secrets and permissions to outside attackers.
So instead of run from the fork on trigger, the cron job runs on an increment from the base repo itself which can then label the PRs. This way, no code is run from the forked repo.
From my research, and what I've seen from the github security model, there isn't a great way to label PRs outside of the cron job.
I will look into this again and see if enabling workflow_run is a possibility to run off of. Stay tuned!
Thanks! workflow_run is new and would run on the upstream repo (not the fork) in a similar nature to an event that runs with a cron schedule but instead it would run when it notices another workflow was triggered (by it's own event). So in that scenario you would setup two workflow files. One would use the pull_request event and do nothing (run echo or something). The other would be this action using workflow_run instead of cron. This action would then listen for the event of the first workflow firing. https://github.com/GhostWriters/DockSTARTer/actions/runs/199933427/workflow this actually shows the usage (note that I have cron in there as well since this action doesn't currently support workflow_run).
I was able to get https://github.com/actions/labeler working with pull_request_target (another new event trigger type that runs on the upstream target of the PR rather than the fork) instead of pull_request. I am no longer using this action, but I opened this issue prior to making the change with the actions/labeler, and I think supporting workflow_run would be reasonable here anyway.
Very very cool, thank you for bringing this to my attention. I'm glad that they are supporting ways for PRs to be labeled on a trigger. I'll see what I can do to switch this over to using workflow_run or maybe better yet see if it's possible now to support it through some kind of pull_request trigger
Issue is stale
/reopen
/reopen
Hi @nemchik - for now, I'm going to recommend people use the Github actions/labeler workflow now since it fully supports pull_request_target. And I think since this is officially supported by github, probably better that then the chron job.
But I'll keep the chron job around for now since it may be useful for batch processing a large number of PRs. Please refer to this doc for more info: https://github.com/jpmcb/prow-github-actions/blob/main/docs/cron-jobs.md
Feel free to open a new issue if you still have questions or feature requests!!!