#github-actions

Merge Schedule Action

15 Jan 2021 in Tech

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, a failure 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 the schedule 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.