Giters

solvaholic / octodns-sync

GitHub Action to test and deploy DNS settings with OctoDNS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Release workflow is easy to screw up

solvaholic opened this issue · comments

commented

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.

commented

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.

commented

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.