dist: don't push images #1365
dist: don't push images #1365
Conversation
|
I think the problem is that you can't have both architectures of the same image tag tracked by the local docker daemon, so buildx has to push them as it makes them - you can't push both architectures later. The docker buildx thing could be a separate even shorter script though. (... I'm currently testing on a debian-11 host system with docker 20.10.5 from the base repos, buildx 0.6.1 plugin manually installed, and qemu 5.2.0 from the base repos with qemu-user-binfmt, and the multi-platform-at-once build fails strangely in some step in the middle, but one-at-a-time works, including for arm64. I'm guessing docker-for-mac works fine doing both concurrently.) |
|
btw it looks like latest tag on docker hub only has amd64 (while v1.2.1 tag has both amd64 and arm64) |
|
Gonna try this docker/buildx#459 (comment) |
|
Updated, also fixed the |
| docker buildx build --tag nsqio/nsq:latest . --platform linux/amd64,linux/arm64 --push | ||
| echo "Tagging nsqio/nsq:v$version as the latest release" | ||
| shas=$(docker manifest inspect nsqio/nsq:$version |\ | ||
| grep digest | awk '{print $2}' | sed 's/[",]//g' | sed 's/^/nsqio\/nsq@/') |
There was a problem hiding this comment.
this looks like a job for jq - but if it works for you it's fine with me
There was a problem hiding this comment.
yes, of course. I wasn't quite sure what our policy for shell compatibility has been, although I suppose you already need quite a few dependencies (golang, docker).
|
sorry for causing this noise, but #1365 (comment) is on the money here. locally you can't store the multi-arch builds :( so you have to buildx build and push in one step. |
| fi | ||
| docker buildx rm nsq-$rnd |
There was a problem hiding this comment.
i think without the buildx rm the builders will pile up. not sure how much resources they use.
it might be possible to do an intelligent builder cleanup prior to setting up new builders using docker buildx ls and interpreting the results. for now on our systems if something happens and the builder gets orphan'd, i've just been removing it manually.
in our circle-ci setup on sso ( buzzfeed/sso#319 ) since we use ephemeral build machines we really don't have to care about the orphan builders.
There was a problem hiding this comment.
I think one could also skip the create and use steps, and just buildx build for local builds, right? It would just cause build cache to accumulate until you docker system prune or similar?
There was a problem hiding this comment.
I like having a namespace to inspect as an artifact of the build. I don't expect this script to be used in any automated context, so practically speaking it's fine.
There was a problem hiding this comment.
for local builds i think just doing an old school docker build is fine. it's really only for the multi-arch push that we need to do the create/use/build-and-push chain.
The expected behavior is for
dist.shto produce a set of local images, to be able to separately push (which matches the behavior of what we do for.tar.gzfiles)