In a previous post I talked about an npm script I had written to be executed by a GitHub action:
Sadly, there's no way to move a file using the Contents API, so the create-then-delete is necessary. This leads to two commits rather than just one. It may be possible to do it in a single commit using the Trees API, but that's a good deal more involved and I don't mind a little noise in the commit history.
I was fibbing! The additional commit does bother me, so I decided to rewrite the publisher to avoid noise in the git history.
My next move was to actually try using the Trees API. It was mostly working before I read Remy Sharp's post on the same topic. Remy uses the metadata of a post to determine if it should be published or not, rather than the directory it resides in.
Using the same idea, the only thing which differentiates a published post and a scheduled post now is that the former has a timestamp in the past. By putting both kinds of post in the posts directory and tweaking the static site builder to filter out future posts, the generator takes care of what to render.
The scheduler now does its thing just by checking the published sitemap against what it expects to see published. When the sitemap is outdated, the scheduler sends a build hook request to Netlify to refresh the rendered content. This means that the scheduler entirely avoids interacting with the GitHub API! No commits necessary to publish. No trees to map through.
GitHub actions have been revised and are now written in YAML. The workflow which handles publications has been updated accordingly, and the publisher script moved to a scripts folder to help keep the project directory clean.