Publish docker image

[tillywoodfield]

Updates to CI/CD:

• Check docker build as part of CI
• On creation of GitHub release, build and push docker image

Other changes:

• Minor fixes which came up while testing deploying in development

Related to #12

[jarofgreen]

Correct me if I'm wrong, but I think this differs from our usual release process in a way that would surprise other staff.

If this happened:

• Merge PR 1
• Update version number to 1.0.0
• Merge PR 2

What would be the state of the release tagged 1.0.0 - would it include PR 1 AND 2? If so this differs from all our other repos (which would only include PR 1) and that might trip people up.

I would suggest that any merge to live builds a docker image tagged "live" and any explicit release made builds a image tagged with the version number and maybe "stable" too?

Then the release process is A) update version number B) Merge that Pr C) Make a new release - and that matches our usual

And there is options on the registry for people who want to follow bleeding, stable or an explicit version

But the other thought here is do we need version numbers? This is an app not a library, so maybe we don't?

[tillywoodfield]

@jarofgreen, I don't think that example is quite correct:

• Merge PR 1
• Update version number to 1.0.0
• Merge PR 2

What would be the state of the release tagged 1.0.0 - would it include PR 1 AND 2?

1. When PR 1 is merged (which has set the pyproject.toml version to 1.0.0), this triggers a workflow to create tag/release for v1.0.0, which in turn triggers a workflow to push the docker image for 1.0.0.
2. If PR 2 is then merged without updating the pyproject.toml version, and it remained at 1.0.0, the workflow which tries to create the GitHub tag/release would fail, because you cannot re-create a tag, so the docker image wouldn't be published.

Therefore 1.0.0 would still just contain PR 1. Someone would have to merge another commit to with a version number bump in order to publish a new version.

Then the release process is A) update version number B) Merge that Pr C) Make a new release - and that matches our usual

I think that is what this process is doing, it just means that the "make a new release" step is automatic when a PR is merged, rather than a manual step that a developer has to do.

But the other thought here is do we need version numbers? This is an app not a library, so maybe we don't?

I think versions are important here as it separates the publishing of a version from the deployment of a version. We can publish a new version, and sanity check it on development, before choosing explicitly to upgrade the version on the production server. As well as this, technically there is an "API" to the pipeline, i.e. the expected inputs or environment variables. Using semantic versioning here means people have to think about breaking changes explicitly, rather than production suddenly breaking because it's always just relying on latest.