Skip to content

use standard TARGETARCH for architecture suffix #13496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ndeloof wants to merge 1 commit into
base: main
Choose a base branch
from
+0 −3
Open

use standard TARGETARCH for architecture suffix #13496

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,9 +188,6 @@ ARG TARGETARCH
ARG TARGETVARIANT
RUN --mount=from=binary \
mkdir -p /out && \
# TODO: should just use standard arch
TARGETARCH=$([ "$TARGETARCH" = "amd64" ] && echo "x86_64" || echo "$TARGETARCH"); \
TARGETARCH=$([ "$TARGETARCH" = "arm64" ] && echo "aarch64" || echo "$TARGETARCH"); \
cp docker-compose* "/out/docker-compose-${TARGETOS}-${TARGETARCH}${TARGETVARIANT}$(ls docker-compose* | sed -e 's/^docker-compose//')"
Copy link
Member

@thaJeztah thaJeztah Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will probably need an update to the official docker image as well; it looks like it currently downloads binaries from GitHub; https://github.com/docker-library/docker/blob/d9bae6519a1b0a9c73fab9a859e0c5c5131b0176/29/cli/Dockerfile#L110-L140

Wondering if we should (to help transitioning) keep both variants for some time.

cc @tianon @yosifkit

Copy link
Contributor Author

@ndeloof ndeloof Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could, but this won't help us detect the places to require an update, as consumer won't notice the breaking change

Copy link
Contributor

@tianon tianon Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, it's better to just rip the bandaid off than double the storage in the hopes that somebody proactively notices, but I do appreciate the thought. 🫶

(If releases could have symlinks in their artifacts, perhaps I would feel differently, but they can't - eventually the bandaid has to come off and it might as well be sooner instead of later.)

Copy link
Member

@thaJeztah thaJeztah Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's reasonable; perhaps we should create a ticket and pin it on this repository for users that arrive here after they get a "not found" error.

(We still have a similar discussion to have for the static downloads from https://download.docker.com/mac/static/stable/, although I guess for those we could have a symlink / redirect)

I mostly was considering that this change may go out in a minor or patch release; if it's a patch release, then users may pay less attention to release notes. I guess it would've been great to make the change with the v5 major version update, but hindsight is a B.

We should also check if there's references to these in our docs; looks like there's at least one in this section; https://docs.docker.com/compose/install/linux/#install-the-plugin-manually


FROM scratch AS release
Expand Down