I’m trying to get ahead on the Action Spotlight series, and needed a way to write and stage a post in advance of it’s Friday publication date.
So, this week’s post covers an action that I needed automatically merge the pull request containing this blog post - merge-schedule-action
.
What does it do?
Merge Schedule allows you to merge pull requests at a scheduled time. The most common use case that I’ve seen for this so far is to merge content into a static site (like this one) at some point in the future.
Scheduled pull requests allows you to stage and approve content ahead of time and have it automatically merged (and deployed if you have a pipeline set up) automatically.
How does it work?
There are two separate handlers in merge-schedule-action
. The first handles a pull_request
being opened
, edited
and synchronize
-d, and the second is run when triggered on a schedule
.
It’s important to note that you cannot schedule merges from forks.
pull_request
The pull_request
handler is a really useful addition to the action. Whenever a PR is opened it checks if the body contains a /schedule
command. If it does, a check is added using the checks
API.
- If the date provided to
/schedule
is invalid, afailure
check is added to the PR to indicate that something is wrong, allowing the author to fix the date. - If the provided date is in the past, a
failure
check is added to the PR (but will still be merged by theschedule
action) - Otherwise, create an
in_progress
check which prevents the PR being merged (unless you’re an admin)
schedule
This is where the bulk of the work happens. This method is triggered on a schedule that you set in your workflow. You can choose any schedule you like, but I’d recommend hourly (if you set specific publish times) or once per day (if you only set a publish date).
merge-schedule-action
starts by loading all open pull requests for the repo the workflow is running under, filtering down to only PRs that have a schedule command and are not from a fork.
Next, it filters out any pull requests where the scheduled date is in the future.
Then finally, it loops though any remaining pull requests, merging the PR and updating the in_progress
check previously added to be completed
.
Top comments (0)