For every canary image build, create an image tag with the commit sha

[alco]

Addresses #1921.

[icehaunter]

I like the idea, but I don't like having a spammed list of tags on DockerHub. A bit sad that we can't have both

[magnetised]

looks good. perhaps to avoid spamming the main image with random tags, @icehaunter, we could push the canary images as electricsql/electric-canary:latest and electricsql/electric-canary:$sha as well as keeping electricsql/electric:canary for backwards compatibility.

i stand by the requirement: it's really important to send an image tag and know that it's not going to change between sending it and it being pulled by the user.

you can just share shas but it provides no documentation to us or the user which version they're running - having the commit sha in the image at least allows for some introspection.

[alco]

@magnetised

i stand by the requirement: it's really important to send an image tag and know that it's not going to change between sending it and it being pulled by the user.

What use cases require such a canary tag to be sent to a user?

Upon taking another look at this change, I wouldn't want to fill up our Docker Hub repo with lots of tags. We may hit an internal limit there or cause the UI to slow down, etc. Canary builds are transient anyway.

If the main purpose is being able to tell which version of Electric is being run, that is solved by logging the version in the log output. I can leave that part of the PR.

When sharing a specific image tag is important on a case-by-case basis, it's always possible to manully push a locally available image to your personal Docker Hub repo, specifying whatever tag you choose, and then ask the user to pull that.

[magnetised]

i stand by the requirement: it's really important to send an image tag and know that it's not going to change between sending it and it being pulled by the user.

What use cases require such a canary tag to be sent to a user?

I literally had to do this when investigating a customer problem. i couldn't send them the :canary tag because that was a moving target and some conversation like "what version does it print when it starts..." doesn't seem very helpful when trying to investigate, probably complex, issues in a customer environment

it's always possible to manully push a locally available image to your personal Docker Hub repo, specifying whatever tag you choose, and then ask the user to pull that.

yes you could do that but why make things difficult for ourselves.

I don't honestly see this as such controversial issue. It just makes a bunch of sense to me to be able to say - "this image" to someone and know that weird things aren't going to happen. I think the idea of using elecric/canary as the name solves the issue with overloading the main image with a bunch of noise and if we hit limits in docker hub then we can address those.

[KyleAMathews]

👍 to named releases for each commit. This is quite common in NPM land & it can be very handy. Granted Docker images are heavier than npm packages so we might run into limits in Docker Hub but we could e.g. just start deleting old ones at that point.

I agree the UI on Docker Hub isn't really designed for this but... that might not be a problem? We have lists of releases elsewhere... but also a new electric/canary neatly solves the issue.