GitHub Actions and Docker build process improvements #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Yes, some of the workflows have copy-pasted elements, but there is no way around that...
And rename the two steps involved to more accurately represent their function (as both now tag "latest").
Bit senseless as the tag would always be created from a commit that has already been linted... Also, the old behaviour leads to the GitHub UI showing the linter checks twice for commits that have a tag attached.
Instead of unconditionally building the Docker image, only build it if it isn't available on Docker Hub. Images are always tagged with their Git commitish, which should ensure we only build each image once (and prevent building/pushing multiple, functionally identical, copies of the same image). Additionally, revert my previous change with regards to tagging "stable" and "latest". The "latest" tag should always (and only) be applied to commits on the main-branch. It's not unthinkable that a release is not created from the HEAD of main, but from an older commit. As such, it is very well possible that when "stable" is created, it is not necessarily "latest"... Furthermore, only non-prerelease versions are tagged with "stable". The others are only tagged with their version itself. Only "clean" semantic versions (e.g. "1.2.3") are considered stable. If anything is appended to the version (e.g. "1.2.3-beta2") it's considered prerelease. Relying heavily on a (creative?) interpretation of the "job.if" feature to ensure proper flow-control. Proof will be in the pudding...
Instead of failing the "pull"-job when the image isn't available on Docker Hub, use output to communicate the result. Also, buildx appears to not support storing multi-arch builds in a tar-file, so for now we'll forgo storing a copy of the build as an artifact of the workflow (marginally relevant to begin with).
First part works, now let's see if it actually wants to push to Docker Hub...
And it's getting way too late; already messed by removing the artifacts (which are necessary to transfer the images from one job to the next).
Using buildx to do multi-arch builds and passing around tar-files with the resulting images doesn't as expected – the regular Docker-client doesn't cope too well with the multi-arch aspect of it all... So, it is either using a single step buildx-command to do everything (building, tagging and pushing), or completely reimplement the convenience of buildx using the regular build and the manifest-tool. The latter would have allowed me to stay with a single, multi-step, workflow with as little duplication in steps as possible. The former appears much simpler though (even if it requires two workflows with a lot of overlap). So, there are now a "docker-ci" and a "docker-push" workflow, with some overlap, but all-in-all a much clearer approach (and fewer magic "if"-statements to control a highly dynamic flow).
Has no added value, just causes a lot of clutter in the GitHub interface...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While attempting to auto-tag the Docker images on Docker Hub (which is working at the moment) some minor nuisances came to light.
Apart from that, I think it's better to split the Docker workflow into two: One for building the image and the second for pushing the image to Docker Hub (to prevent building the same image multiple times). Only thing to figure out there is how to use the artifact from one workflow in another...While I'm at it, also see if it's possible to use
buildxto build Docker images foramd64andarmhfarchitectures too.Split the Docker workflow into two separate ones: One for CI (do a multi-arch build and store the resulting images as artifacts) and one to publish to Docker Hub (for every commit and the
main-branch and for every tag created).