The original event used, 'pull_request', runs in the context of the
pull request. In the case of pull requests created from forks this means
that a read-only GitHub token is used for API calls, and thus the
call used to assign the milestone fails.
The fix is using the 'pull_request_target' event, which runs in the
context of the base branch, and thus with a read-write token. See:
https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target
Also, added a warning message when no milestone without a release
branch is found and thus the newest existing milestone is assigned
(this is a fallback that should normally not happen).
If the GH API call to assign the milestone to a merged PR returns an
error, the data returned from the call will be dumped to the console,
and thus will be readable by looking at the action execution log.
The milestone is chosen as follows:
1. List all the open milestones with a title of "X.Y.Z"
2. Sort them desc using verson_compare
3. foreach them in order, and take the last one not having a
corresponding release branch ("release/X.Y")
barryhughes
Jonathan Sadowski
jamelreid
Nestor Soriano
Néstor Soriano