Comments (7)
doesn't do anything for intermediate stages?
It only has an effect atm if the source parameter for FROM
is multi-platform image or multi-platform build result(via named context). The stage itself can be any stage in the Dockerfile.
Do you think there's any other way to achieve what I want (besides duplication)?
If the commands are same for the stages defined with different platform sources(that result in same platforms based on config) then buildkit will internally merge the commands and they only run once.
from buildkit.
I kind of understand the current behavior. But this is still confusing. Do you consider overriding the TARGETPLATFORM of stage as a valid feature request, and to be included in the future releases? If so, I can investigate more and may create PR for this.
The workaround currently requires duplicating many code in Dockerfile, or just spliting the Dockerfile into multiple Dockerfile and build them in sequence. They are not ideal.
from buildkit.
Do you consider overriding the TARGETPLATFORM of stage as a valid feature request,
Supporting FROM --platform=.. <basestage>
essentially means that the basestage needs to be evaluated multiple times.
Eg.
FROM --platform=amd64 alpine AS base
RUN cmd
FROM --platform=arm64 base
COPY --from=base /foo /bar
RUN smth
Building this Dockerfile with default args would run cmd
twice for both architectures (in the internal LLB graph this RUN would generate 2 different container exec steps).
Same as above:
FROM --platform=amd64 alpine AS base
RUN cmd
FROM --platform=arm64 alpine AS base-for-stage1
RUN cmd
FROM base-for-stage1
COPY --from=base /foo /bar
RUN smth
So the answer to your question depends on how much a change like that would affect the codebase and if it would increase the complexity of generating LLB graph a lot. If not then I would be ok with it. Otherwise we can add a warning to let user know that --platform
only affects resolving multi-platform images.
from buildkit.
Yes, this is same as #4237 . --platform
is a hint for pulling the image if it is a manifest list. In your case it is a stage that is already resolved to a specific platform.
Implicitly your code is:
FROM --platform=$TARGETPLATFORM busybox as base
ARG TARGETPLATFORM
RUN echo $TARGETPLATFORM > /plt
FROM --platform=$TARGETPLATFORM base as base-target
FROM --platform=$BUILDPLATFORM base as base-build
Additionally --platform=$BUILDPLATFORM
does not change the meaning of TARGETPLATFORM
inside the stage.
FROM --platform=$BUILDPLATFORM alpine
ARG TARGETPLATFORM BUILDPLATFORM
RUN env && echo "These do not match in cross compiling"
from buildkit.
Additionally
--platform=$BUILDPLATFORM
does not change the meaning ofTARGETPLATFORM
inside the stage.
So basically FROM --platform=$BUILDPLATFORM
doesn't do anything for intermediate stages? I guess I agree with AkihiroSuda from the other thread that that is quite surprising and a warning would be nice. Also the docs are very lightweight on this topic.
Do you think there's any other way to achieve what I want (besides duplication)?
from buildkit.
@tonistiigi I think we are hitting the same issue. In my case, I want to insert an arch independent step into the build process, so that it does not need to be done multiple times for each arch.
With this Dockerfile (I'm building on an arm64 host)
FROM busybox as env
# install build deps
FROM --platform=$BUILDPLATFORM env as gen
# download source code & ./autogen.sh
RUN uname -m && [ $(uname -m) = "aarch64" ] && mkdir /src
FROM env as build
# build source code, mount source code from gen stage
RUN --mount=type=bind,from=gen,source=/src,target=/src,rw \
echo "building"
I expect the build to success, but I got
=> ERROR [linux/amd64 gen 1/1] RUN uname -m && [ $(uname -m) = "aarch64" ] && mkdir /src 0.1s
=> CACHED [linux/arm64 gen 1/1] RUN uname -m && [ $(uname -m) = "aarch64" ] && mkdir /src 0.0s
=> [linux/arm64 build 1/1] RUN --mount=type=bind,from=gen,source=/src,target=/src,rw echo "building" 0.1s
------
> [linux/amd64 gen 1/1] RUN uname -m && [ $(uname -m) = "aarch64" ] && mkdir /src:
0.073 x86_64
------
Dockerfile.test:6
--------------------
4 | FROM --platform=$BUILDPLATFORM env as gen
5 | # download source code & ./autogen.sh
6 | >>> RUN uname -m && [ $(uname -m) = "aarch64" ] && mkdir /src
7 |
8 | FROM env as build
--------------------
error: failed to solve: process "/bin/sh -c uname -m && [ $(uname -m) = \"aarch64\" ] && mkdir /src" did not complete successfully: exit code: 1
I would expect the gen stage only run once on arm64, but it also runs on amd64. Any suggestions please?
from buildkit.
I would expect the gen stage only run once on arm64, but it also runs on amd64. Any suggestions please?
You need to do something similar to this:
FROM busybox-build as uv-amd64
# install deps
FROM busybox-build as uv-arm64
# install deps
FROM uv-$BUILDARCH as uv-build
FROM uv-$TARGETARCH as uv-target
from buildkit.
Related Issues (20)
- `checksum`ing "local files" for remote builder contexts HOT 2
- Docker buildkit stuck with high CPU and unresponsive HOT 7
- COPY argument `--chmod` not working on directories
- dockerfile:1.7-labs: COPY fails where there exists broken symbolic link and --exclude is specified
- ResourceExhausted: grpc: received message larger than max (_ vs. 4194304) HOT 1
- COPY creates file with incorrect contents HOT 2
- Th
- Getting error when trying to build multiarch images with an argoworkflow - failed to solve: process "/dev/.buildkit_qemu_emulator HOT 2
- Network Issue with using RUN in dockerfile in Windows Builds HOT 11
- Debug upload to gha cache HOT 1
- Buildkit export getting delayed on exporting layers stage HOT 2
- docs: proposal to raise awareness about an unexpected behavior of COPY --link
- [Feature Request] Add --cache-repo option to cache layers
- The heredoc syntax is not being recognized. HOT 8
- dockerfile: improve caching source metadata resolve requests
- Option to disable OpenTelemetry
- Option to disable submodules / recursive clone
- Rename JSONArgsRecommended to ExecArgsRecommended
- Verify linting rules descriptions and links HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from buildkit.