build: PRs should be assigned a milestone upon merge

[nitrocode]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story

It would be nice to assign the milestone of the next release upon merging a PR

The benefit of this would be that maintainers would no longer need to

• manually set the milestone prior to merging
• backfill milestones using issue filter logic
  • e.g. is:pr is:merged no:milestone merged:2022-10-05..2022-11-28
  • where 2022-10-05 and 2022-11-28 are the dates of releases

This will also remove errors in assigning milestones.

Another benefit is that we will be able to always know which PR is in which release. If there is ever an issue, it will be that much easier to triage.

Describe the solution you'd like

It would be great if goreleaser did this out of the box.

If not, then we'd need a github action that

• runs on PR merge
• checks if there is a milestone on the PR
• if so, do nothing
• if not
  • detects the most recent open milestone name
  • applies the milestone to recently merged PR

Looks like the terraform aws provider project does this

• https://github.com/hashicorp/terraform-provider-aws/pulls?q=is%3Apr+is%3Aclosed
• https://github.com/search?q=repo%3Ahashicorp%2Fterraform-provider-aws%20milestone&type=code

If you look at how they implement it, it looks like

https://github.com/hashicorp/terraform-provider-aws/blob/main/.github/workflows/milestone.yml

• they add the current milestone as a header at the top of the CHANGELOG
• then milestone.yml will
  • get that milestone name
  • get the milestone number from the name
  • use the breathingdust action to set the milestone on the closed (merged) pr

Describe the drawbacks of your solution

Describe alternatives you've considered