Project Management Automation: Avoid milestone task for forks#20049
Project Management Automation: Avoid milestone task for forks#20049
Conversation
|
Is it possible to comment on the PR and ping the merger otherwise? or are comments limited in the same way? |
If it happens in response to the There's a note there about custom tokens as secrets. Based on the reasons these permissions are read-only in the first place (limiting what can be done from forks), I'm not entirely sure about how secure this would be. |
epiqueras
left a comment
There was a problem hiding this comment.
GitHub is aware of this limitation and working on an alternative. Let's do this for now:
Separately, there might be alternatives to explore here, where the event is handled in response to the commit as it ends up being pushed to master. In other words, some combination of:
@aduth Do you want to tackle it, or should I?
I'll likely not be able to prioritize this 'til after next week's 5.4 beta. Feel free to take it up if you're interested, otherwise I can plan to revisit it later. |
Previously: #20021
Related: #17324
The milestone Action currently generate errors for merged pull requests originating from a fork repository:
https://github.com/WordPress/gutenberg/commit/084f38a21662a27d00bb3d32f350e9141f9caf38/checks?check_suite_id=439313372#step:4:12
The milestone task was originally omitted from the conditional runs implemented in #20021 based on the incorrect assumption the merge event would be considered with higher permissions, even if the pull request being merged originated from a fork. This is clearly not the case, and it seems all
pull_requestevents will be subject to these restrictions.https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token#permissions-for-the-github_token
Understandably, this diminishes the value of this automation, as we can't rely that the milestone will have been applied.
Separately, there might be alternatives to explore here, where the event is handled in response to the commit as it ends up being pushed to master. In other words, some combination of:
pusheventmasterbranch