Add docker-build workflow (#942)

[janw]

Checklist

• All new and existing tests are passing
• (If docs changes needed:) I have updated the documentation accordingly.
• I have added an entry to CHANGES.rst because this is a user-facing change or an important bugfix
• I have written proper commit message(s)
  

What changes does this Pull Request introduce?

This PR adds an automated docker build using GH actions.

Images are build automatically for the following patterns:

• PR is opened/updated: builds and tags the image but does not push it to the registry (this is done to verify a successful build; example build)
• Push to master (i.e. merge a PR): build and tag image with :latest (example build)
• Push a new tag (i.e. release new version): build and tag with
  • major version only (i.e. :0), and major+minor version (i.e. :0.14) (example build)
  • full version (i.e. :0.14.1-post.0) (example build)

Furthermore this includes a multi-arch docker build: the image will be build for linux/amd64, and linux/arm64/v8, arguably the most common platforms for both large production environments and small-scale self-hosted applications.

Example image are available via my fork: https://github.com/janw/isso/pkgs/container/isso

Why is this necessary?

• Removes necessity to manually build container images, and resolves Please add Multi-CPU architecture for Docker image #942 in the process.

[jelmer]

We probably need to work out where exactly we want the docker images to live, GitHub doesn't make it very easy to publish docker images cross-user/org.

@ix5 do we want to move the main repo to the isso-comments org at some point?

[BBaoVanC]

What other repo is there, why not just publish the images to here?

[jelmer]

This PR uses the ghcr.io/isso-comments namespace, and I think the plan is also to move this repo to GitHub.com/isso-comments/isso eventually

[ix5]

I talked to @posativ about moving the repo over to the org, but can't quite remember what prevented us from doing that.

PR itself LGTM.

[ix5]

Just to make it clear, this is blocked until we have a decision about moving the repo over to the org.

[jelmer]

Just to make it clear, this is blocked until we have a decision about moving the repo over to the org.

could we just publish to posativ/isso in the mean time?

[ix5]

Just to make it clear, this is blocked until we have a decision about moving the repo over to the org.

could we just publish to posativ/isso in the mean time?

That would be fine by me, but I don't have access to the Settings repo tab (for posativ/isso) to add a deploy key as a secret.

I do have access to the isso-comments org and could add the deploy key as an accepted one, just as I have done for the GitHub pages repo (see sso-comments/isso-comments.github.io).

So either way, we're blocked until Martin finds time to act on this.

[janw]

Just checking in, is there anything you need from me to help move this forward? I'd be happy to assist in any way necessary.

[jelmer]

Thanks; I think we're basically just waiting from a response from @posativ

[jelmer]

The repo has now been migrated, and references are being updated in #996 so let's land this!

[ix5]

I hadn't realized this at the time, but this change means we're re-building the :latest docker tag on every push to master.

Up until this change, I had handled the docker image policy as :latest for the latest tagged release (0.13 at the time IIRC) and :dev for images from the master branch.

Could we please change back to :latest being the latest release, not "bleeding edge" master branch?

[ix5]

The way I read this, the action rebuilds and pushes the :latest image on every push to the default branch (=master).

[jelmer]

I think it's pretty common in docker that latest just refers to whatever the latest thing that was built and pushed was; the way the latest tag works in docker this is pretty common hard to avoid.

I think that if we want to have a docker tag for the latest release, we should just create a new ":release" tag and update that accordingly.

That said, I think it's good practice for people to specify an explicit version (v1.0) as a tag so that their service don't get silently upgraded whenever they restart their services, including any regressions that may cause.