Project Management Automation: Avoid milestone task for forks

[aduth]

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_request events 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:

• The push event
• Conditioning on commits that occur in the master branch
• Deriving a pull request associated with the commit
  • Related: https://developer.github.com/v3/repos/commits/#list-pull-requests-associated-with-commit (still experimental as of the writing of this pull request)
• Applying milestone to the pull request

[youknowriad]

Is it possible to comment on the PR and ping the merger otherwise? or are comments limited in the same way?

[aduth]

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 pull_request event (the merging of the pull request), my understanding is that all of its permissions are read-only:

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token#permissions-for-the-github_token

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]

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?

[aduth]

@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.