In my previous post I wrote about the awesome tool "Code Search" from SourceGraph. This tool helped me locate a bug in the Spellcheck GitHub Action, this release includes the fix.

First a little backstory, when I started to look into making the action faster, with the use of a static Docker image, instead of one which was built with every run of the action. I decided to point to the DockerHub tag latest. This was convenient at the time, because things were new and unstable and it allowed for me to just get the latest Docker image, without having to do a new release of the action - and of course I forgot all about it.

When I did the release for 0.19.0 I found out that some of the older Docker images, where being downloaded from DockerHub. This resultet in some PRs, but something puzzled me, there was references on GitHub to older Docker images, which had been removed from DockerHub.

I located a repository which referenced to release 0.11.0, which had recently built successfully.

I dug around some more and found out that the project was pulling the image with the tag: latest and not 0.11.0 as I expected.

With release 0.20.0, it now points to the Docker image with the same tag.

This means that I have to:

1. Upload (push) the tagged Docker image to DockerHub prior to committing and tagging the code on GitHub.
2. When the code is committed and tagged, I can test it out on one of my other repositories, since I get point to the GitHub release.
3. When this succeeds, I can push the Spellcheck GitHub Action to the GitHub Marketplace
4. And finally I can push the Docker image with the latest tag to DockerHub.

There might be a smarter way to do this and I will look to improve this as I get it to work as a manual process.

The reason why it is important to rely on sticky release tags, is that latest is defined to be unstable and the introduction of a new release, which could break backwards compatibility, would render havoc for the users of the GitHub Action, when pulling latest unknowingly, since they actually point to a tagged release, but it is not what they would get from DockerHub.

This is an important bug fix release and I am just happy I have not broken anything else, well at least that I know of.

Change log

0.20.0, 2021-12-21, bug fix release, update recommended

• Made the version specified in the action.yml follow the version indicated in the repository. Apparently we where pointing to latest, which is good when and if we are backwards compatible and yes we are still in alpha expressed semantically by the version numbers starting with 0 as in 0.20.0. This would however allow for us to release breaking changes, without breaking a lot of workflows, which would fetch the latest Docker image, which can be either unstable or a major release