Github Deployment Gotchas

Ran into these. I dunno, I run into things, okay?

Turns out nobody cares about your cute lil "draft" releases

By nobody, I mean the Github Actions webhooks or whatever that listen for workflow trigger events. To me this is madness, because a draft is precisely what I want to listen for, to kick of a deployment workflow which, let's face it, may or may not faceplant. But no. That whole "oh look, a draft release!" event just gets pissed into the wind and GA is whistling to itself, thumbs in its frigamore ears, not listening.

Also, releases don't die

• publish a release with:

  • pre-release checkbox checked
  • a useful tag, e.g. release/1.2.3
• once deploy is successful, uncheck pre-release.

Simple. But say it wasn't successful. Say you want to get back to how things were, and forget unfortunate recent events. Ha! Chance would be a fine thing. To back out of the release entirely, github has made this difficult to do for non-enterprise users, so plebeian freeloaders have to do this instead: - locally, do a git push --delete origin <tagname>. This reverts the release to a plain 'draft' state. - go into the github ui, click Edit on the draft - you will now (finally!!) have an option to delete the draft entirely.

Releases are sticky

• even with pre-release checked, github caches the repo files which it zips and attaches to your release.
• Thereafter, it will be deaf and blind to whatever changes you make to the repo. You will have to nuke the release entirely if you need it to reflect changes.

Workflows are sticky

• Github actions will only list workflows that have been committed to the main branch. If they're hanging out on some other branch and not merged yet, you're not gonna see em.

• Github actions also caches your workflow, based on the filename of the .yml and even the workflow name!! If it suddenly stops paying attention to your workflow updates, you might have to:

  • rename your yml file
  • rename the workflow name as well, if the above fails.

Here's the worst part: after effectively being forced to introduce a new workflow, the old one does not die. It can't die, unless you manually go to each run and nuke the logs. That's not gonna be practical for a workflow that's been around for a while. So, all you can really do is manually disable the old workflow. Ughetty-ugh to the power UGH.