Framework: Introduce "Milestone It" GitHub action

[aduth]

Closes #9239

This pull request seeks to introduce a GitHub Actions Docker image configuration. The intent will be that, combined with actions/bin/filter merged, it can be used as an action on the pull_request event to assign a merged pull request into the next milestone, creating the milestone if it doesn't already exist.

Testing Instructions:

It's a bit difficult. I tested using my own fork of the repository. Then you'll need to create a personal access token. Then save a Webhook payload example for a PullRequestEvent and assign the "number" to a real issue or pull request in the forked repository.

At which point, from the root of Gutenberg you can do:

GITHUB_EVENT_PATH=~/Desktop/demo-pr.json GITHUB_TOKEN=... GITHUB_REPOSITORY=aduth/gutenberg sh .github/actions/milestone-it/entrypoint.sh

You should expect to see that (a) a milestone for "Gutenberg 5.8" is created and (b) the issue or pull request is assigned to it.

[youknowriad]

would be good to set the description and the date automatically as well (the date might be harder)

[aduth]

would be good to set the description and the date automatically as well (the date might be harder)

We don't currently have a description for these milestones. Maybe something like..

Tasks to be included in the Gutenberg 5.8 plugin release.

?

Date... would be harder 😆 I'll think on how it might be implemented, but otherwise I could imagine it to be a future enhancement.

[youknowriad]

Tasks to be included in the Gutenberg 5.8 plugin release.

WFM

[aduth]

the date automatically as well (the date might be harder)

A thought on how this might be implemented:

1. Compute the number of versions which should have elapsed since we started strictly adhering to the two week release rhythm (or, any reference version to compare against which falls in this range).
2. Use date command with arithmetic to offset the start date (the date of the first bi-weekly release) by 2 * num_versions weeks

e.g.

num_versions=8 # 5.8 - 5.0
weeks=$((num_versions*2))
reference_start_date=1549411200 # 5.0 release
due=$(date -u -r $reference_start_date -v+$(echo $weeks)w)

echo $due
# Wed May 29 00:00:00 UTC 2019

Unsure if this will be made complicated by differences in the date command between OS (macOS BSD date vs. Ubuntu GNU date, specifically on arithmetic via -v vs. -d)

Edit: Probably want to set the due date by RC, not by final release.

[aduth]

It occurs to me: Are there pull requests we should exempt from this behavior? I'm wondering if mobile changes, for example, are considered as part of a plugin release. I suppose it's fair to say they are?

Wondering partly because there's currently an open "Mobile v1.0" milestone. Since an issue can only be part of one milestone, if we'd want to start having mobile release milestones as well, we might have to figure out how to go about distinguishing which pull request should go where.

Since that milestone appears unused, I don't think it should be an issue for the time being.

[youknowriad]

@aduth The only things I exclude from these are the version bump commits, this is not concerning as these commits will happen in master directly with the release tool.

But I think we should exclude the PRs that are already milestone because sometimes we assign a previous milestone to do a minor, RC fixes...

[aduth]

But I think we should exclude the PRs that are already milestone because sometimes we assign a previous milestone to do a minor, RC fixes...

For posterity: An elegant approach to this could be a separate custom action has_milestone which accepts as argument either a named milestone, an empty (unassigned milestone), and optionally allows wildcards. The flow could then be pull request -> filter(merged) -> has_milestone("") -> milestone_it.

Instead, for now I will probably just add in the logic to check in this script directly 😄

[aduth]

Pushed up a couple more changes to reflect feedback. Starting down the path to implement the date handling, I was first going to grumble about the new, more-difficult testing instructions, but in retrospect am glad to have gone through the effort, since it helped reveal that there would have been problems in the entrypoint not being executable (fixed in 8808812).

Once the date work is implemented, to avoid issues of OS differences in date implementation, it'll be best to run through the container directly, meaning it must be built as an image and run through the docker command.

Example (run command needs substitute values):

docker build -t milestone-it .github/actions/milestone-it
docker run -v=$(pwd):/work -w="/work" -v=/path/to/pr/payload:/run -e "GITHUB_EVENT_PATH=/run/demo-pr.json" -e "GITHUB_TOKEN=..." -e "GITHUB_REPOSITORY=aduth/gutenberg" milestone-it

[aduth]

I've pushed changes to assign a due date for the milestone. I think this should be effectively complete now.

Example milestone (with description, due date, pull request assignment) from my testing: https://github.com/aduth/gutenberg/milestone/1

[youknowriad]

Thanks Andrew, let's try it.

[aduth]

Pushed a small fix in 17b5085. The previous implementation would have relied on the first result of the milestones API request to have been the one we're searching for, and would not have worked if it was not (reference).

As a general reflection of implementing this: It works well enough, but I feel like writing shell scripts for these sorts of tasks is cumbersome and error-prone. Part of this may be my own inexperience in crafting them, though I think it's fair to say this would be shared by future maintainers. Since Actions are simply Docker images, there's nothing stopping us from crafting the image to install Node and run JavaScript instead, where we may benefit from our collective expertise, and perhaps even tooling patterns like unit tests, etc which would otherwise not be straight-forward as proposed here. There's a negligible amount of additional overhead in increasing the number of dependencies, but I think it would be worth considering for future custom actions.