-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Framework: Introduce "Milestone It" GitHub action #15826
Conversation
-X POST \ | ||
-H "Authorization: token $GITHUB_TOKEN" \ | ||
-H "Content-Type: application/json" \ | ||
-d "{\"title\":\"$milestone\"}" \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be good to set the description and the date automatically as well (the date might be harder)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tasks to be included in the Gutenberg 5.8 plugin release.
WFM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the date automatically as well (the date might be harder)
A thought on how this might be implemented:
- 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).
- Use
date
command with arithmetic to offset the start date (the date of the first bi-weekly release) by2 * 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.
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. |
@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... |
For posterity: An elegant approach to this could be a separate custom action Instead, for now I will probably just add in the logic to check in this script directly 😄 |
Pushed up a couple more changes to reflect feedback. Starting down the path to implement the Once the date work is implemented, to avoid issues of OS differences in Example (
|
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Andrew, let's try it.
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. |
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 thepull_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:
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.