Release workflow is easy to screw up

[solvaholic]

What I did

I don't wanna talk about it.

What I expected to happen

:magic:

What happened instead

😢

I published octodns-sync v2.1.1 to the Marketplace before pushing the :2.1.1 Docker image and bumping the :2 tag to match it.

Additional info

After I screwed up v2.1.1 I made a release checklist to organize the steps and keep on track.

I'd like to trigger the release workflow on a single event.

I think triggering from release feels inside-out because it would publish the release before the rest of the work is done. Unless .. will a draft release trigger a workflow? That'd be sweet.

Otherwise I think it could work to build a workflow triggered on workflow_dispatch that'd do all the steps, given a branch to work with and a release number to generate.

Before spending much time on it, though, probably see how a few other projects automate release workflows.

[solvaholic]

In thinking about this I think automating any deployment could, in addition to simplifying the release workflow, also simplify the process of testing changes before merging to main.

I think of deployment, in this case, as:

• Changes have been pushed to commit SHA abc1234
• Build the Dockerfile at abc1234 and push it to ghcr.io with tag abc1234
• Changes are available via docker pull and in workflow runs as, for example, octodns-sync@abc1234

Given that deployment, I think shipping abc1234 as a release could be as straightforward as pushing relevant Git and Docker image tags and publishing the release on the repository.

[solvaholic]

With a61d444 I'm going to call this done-enough. At least for now.

Here are some assumptions I made along the way:

• There's one person creating branches and releases this repository.

  While I would be thrilled to add collaborators, some central tooling relies on a personal access token I'm not comfortable sharing access to. So: Adding collaborators, if/when that time comes, may require changes to tooling.

• It's OK to not push major version tags for Docker container images.

  Currently I do not envision using them, or requiring them for this Action. I mean the tags that would let a person run this to pull the most recent :2.x.x version of the image:

  docker pull ghcr.io/solvaholic/octodns-sync:2
  

• It'll be OK to follow up separately to automate bumping of the repository's major version tags.