Add a GitHub workflow cache to manually purge the Cloudflare cache

[dscho]

Changes

• Adds a workflow definition to manually trigger a Cloudflare purge

Context

In #2086, and then also in #2093, we saw problems where the cache-purging logic that is supposed to be run as part of deploying the site seems not to have worked as expected. The symptom is that the CSS (whose file name now changes when its contents change) isn't loading, because the front-page still serves an older version (one that references a no-longer-existing CSS).

Let's add a way to manually purge the cache. It is totally possible that this is one of those famous "Close Door" elevator buttons that fool us into believing that we did something, anything. But just in case it isn't such a no-op, let's have a GitHub workflow so that we can trigger a Cloudflare cache purge manually.

Here is the workflow run that I would like to believe fixed the issue.

[jvns]

Do you think it would make sense to purge the Cloudflare cache on every deploy? I used to do that when I used Cloudflare for my personal site.

[dscho]

Depending how often this happens (this is now the second time that I observed this within a short timespan), we might want to implement some more work-arounds:

• add a test to the deployment logic that verifies that the front page is served using the expected CSS filename, and if it isn't, calls that purge_cache API again, waits a while, and re-tests. Maybe repeat that a couple times if necessary, and error out if even a couple retries failed to have the desired effect.
• in cb4696d, I added a work-around to ensure that the previously-deployed CSS file (and JS files) is served in addition to the current one. We may have to reinstate logic like that, but this time downloading the files from the site (by downloading the top-level index.html file, erroring out gracefully upon a 404 in forks, then parsing that file for the minified application.css and application.js and then downloading them to public/).

I'd rather avoid this, as it is hacky, but hey, if it is necessary it is necessary.

[dscho]

Do you think it would make sense to purge the Cloudflare cache on every deploy?

@jvns we do that. Or I should say, based on recent experience, we try to do that. 😁

[jvns]

Oops, I missed that!

In the past I've dealt with this by building a way to serve historical versions of the old CSS/JS (maybe for 6 weeks or so), I wonder if it would make sense to hack together some kind of system like:

1. make a new bundle (saved somewhere in GitHub, maybe in releases?) of all the historical CSS and JS from all old builds
2. every time you build, download the old bundle, add the new CSS and JS, and re-upload it
3. put all the CSS and JS from the bundle in public/

Seems like probably too much work though, your idea to just try purging the cache again seems much easier.

[dscho]

In the past I've dealt with this by building a way to serve historical versions of the old CSS/JS (maybe for 6 weeks or so)

We could do this. Basically, we would add a new directory and after Hugo generated the files, copy the application*.js and application*.css there (unless they are already there), then add a record to a JSON "database" when these files were generated. After that, remove the ones that hadn't been used in the past 6 weeks, and finally copy the others to public/. The slightly tricky thing here is that the eviction should not be based on the timestamp when those files were first generated, but on the timestamp when they were superseded. The recorded timestamp should kind of be applied to the previous file version.

There is already a step in the deploy-to-github-pages Composite Action to push updates, and we could repeat that in case of newly-cached or evicted files.