untested: Use same image for :latest :x.y.z :x.y and :x docker tags

[morganchristiansson]

I'm a bit of a noob with github actions so not sure how to test this... feedback?

[LongLiveCHIEF]

@morganchristiansson thanks for the PR! I love the idea, but unfortunately it's not future proof. The HackerHappyHour/tagging-strategy action was specifically designed for the future needs of this project, in that we can define image variants as part of the semver strategy and build dynamically based on conditions.

Adding all the tags to the same build command eliminates the ability to do that. For example, the current file allows us to build X.Y.Z, X.Y, and X of all variants... but not overwrite latest, in the event that we want to re-build and patch a previous version of the octoprint image.

Also, very soon we'll have image variants such as -minimal and possibly even variants for different base images/distros, and the current build/release command allows for that by simply adding to the matrix.

We are using a distributed cache (octoprint/octoprint:cache) so that each image that gets built uses the same layers for cache, so it's not causing any real issues for the builds.

This idea still has merit though, since perhaps we could write the tag string array to a variable and just use that variable in the final command, so that we can still use the dynamic tag resolution but have all those tags passed to a single command.

While I don't think I can accept this pull request as is, it's worth considering how to include your intent in the work I'm doing over the next 2 weeks to create the expanded built system.

[LongLiveCHIEF]

Also, I noticed you caught that typo. In the future, consider splitting those up into separate PR's, since one is a fix, and one is a proposed enhancement. I would have been able to accept the one even if I didn't accept the other.

I made the fix myself since I'm doing work on this today and for some of the roadmap stuff I mentioned above, and that fix will be needed. I hate not having you as a contributor since you were the one who caught it.

[morganchristiansson]

Sorry for late reply. And bless - I too have strong feelings about git history :-)

Anyhow I was just expecting the docker image id for :latest to match one of the other tagged images and it turns out they are separately built images of same version. Doesn't really matter I guess just something I use to confirm version of :latest.

Thought it made sense to build 1 image per GH action run but you're probably right that HackerHappyHour/tagging-strategy is better for you. Was just showing off creating multiple tags for a single image id.

[LongLiveCHIEF]

@morganchristiansson before your pull request I didn't realize i could use multiple tags in buildx.

I've started working on docker/metadata-action#18 to allow use of the new official docker actions with this workflow as a result.

[LongLiveCHIEF]

@morganchristiansson thanks largely to your original PR, I've done some great work to improve the builds and remove the matrices, dynamically determining the image tags needed for each build command.

While I didn't wind up going with your PR, (I wanted to implement support for new official docker actions), I'd like to call you out in special thanks either in the README or the CHANGELOG (which will be created soon). Is that ok with you?

[morganchristiansson]

Super late reply again :-)

Awesome to read. Your reply is enough. Thank you and you're welcome.

Yeah multiple tags is awesome. Not sure plain docker build accepts multiple -t but you can run docker tag to copy the tag to new names and push them. With buildx and other tools there's other methods to create and publish multiple tags in 1 command.

It's a bit of a go-to pattern for me to ctrl-f the image id on docker hub to see what tags are sharing the same image