Repository navigation
Release ARM CLI artifacts - #4841
Conversation
Signed-off-by: Ali Ariff <ali.ariff12@gmail.com>
Signed-off-by: Ali Ariff <ali.ariff12@gmail.com>
There was a problem hiding this comment.
Thanks @aliariff 👍
I'm testing this locally with
DOCKER_BUILDKIT=1 DOCKER_MULTIARCH=1 DOCKER_PUSH=1 bin/docker-build-cli-bin
The final image gets built and pushed into gcr.io correctly, tagged gcr.io/linkerd-io/cli-bin:git-22f8aee9.
But the command ends with an error:
...
=> [stage-4 2/2] COPY --from=golang /out /out 0.3s
=> exporting to image 62.1s
=> => exporting layers 7.2s
=> => exporting manifest sha256:da4812de895590b912ae0b77ebf74f567e381dad92c47af114edbb039a503d98 0.0s
=> => exporting config sha256:b3581bfd2021e102695d84acd8cf8aa508e57ad0c1aaade811962a846b78a388 0.0s
=> => pushing layers 53.7s
=> => pushing manifest for gcr.io/linkerd-io/cli-bin:git-22f8aee9 1.1s
gcr.io/linkerd-io/cli-bin:git-22f8aee9
/home/alpeb/src/pr/4841/linkerd2/target/cli/darwin/linkerd
/home/alpeb/src/pr/4841/linkerd2/target/cli/windows/linkerd
/home/alpeb/src/pr/4841/linkerd2/target/cli/linux-amd64/linkerd
Error: No such container:path: 4e05b40b37f90fb3f649aa261dbfe83d821965ffed9a17f6cbf4a6ebc0ed8867:/out/linkerd-linux-arm64
And the arm binaries aren't getting copied to ./target/cli.
I think what's happening is that in the last part of bin/docker-build-cli-bin there's a docker create "$IMG" which is picking an image that resides locally in docker images, which is an intermediary image (that doesn't have the arm binaries) and not the same final one that got pushed into gcr.io.
If I issue:
DOCKER_MULTIARCH=1 bin/docker-pull-binaries git-22f8aee9
Then that local image is replaced by the full one, and indeed I succeeded on copying out of it the arm binaries.
This might happen because we couldn't use --load in docker build buildx so the final image is pushed but not loaded locally and so the last part of bin/docker-build-cli-bin can't access it. A workaround would be to pull the image before doing the copying.
...But maybe it's not suitable to use --platform=amd64 in this case? Not only because we're just targeting one arch, but If we remove that we can use --load and then the build script will be able to use local images. Let me know what you think.
|
Sorry @aliariff , my last comment was utter nonsense! I had seemingly previously built a single arch image and that's what the script used. After clearing my local cache it's working fine. I'll test now the release in my fork and report back. |
There was a problem hiding this comment.
The release workflow is working fine 👍
Would you push an empty commit to trigger the build again? It ran fine but it didn't got reported back into the PR.
Signed-off-by: Ali Ariff <ali.ariff12@gmail.com>
1c8e7f8 to
b7fc557
Compare
There was a problem hiding this comment.
Thanks for testing this in your fork @alpeb.
Changes look good to me.
|
Before merging this one up, we'll wait for linkerd/website#785 to get merged first. |
@cpretzer @alpeb @kleimkuhler
Changes
amd64forcli-bin. Inside that image, it will consist of multiple architecture binary files. It used the multi-stage build pattern to produce those binaries. RefTODO
Note
Manual tested in a local fork. https://github.com/aliariff/linkerd2/releases/tag/stable-test