Skip to content
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.

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

Proposal: ARCH statement in builder #18383

Closed
lowenna opened this issue Dec 3, 2015 · 7 comments
Closed

Proposal: ARCH statement in builder #18383

lowenna opened this issue Dec 3, 2015 · 7 comments
Labels
area/builder kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny

Comments

@lowenna
Copy link
Member

lowenna commented Dec 3, 2015

Currently, it's not possible to have a cross-architecture dockerfile. This can be evidenced by the docker CI itself where the main image built downloads busybox (linux/amd64) in the dockerfile. Subsequently hoops are jumped through during test-integration-cli which ends up in .ensure-frozen-images to download/update/tag the linux/arm images to ARM specific ones.

This architecture problem obviously also applies to Windows as well, but is not a Windows specific proposal. I suggest using golang build-style directive-type syntax as a preface to a command. So a dockerfile might contain something like

ARCH !windows: COPY linux.sh /runthis.sh
ARCH windows: COPY windows.cmd /runthis.cmd
ARCH !windows: ENTRYPOINT /runthis.sh
ARCH windows: ENTRYPOINT /runthis.cmd

or some more complex examples using the golang type and/or syntax

ARCH linux,freebsd 386: <somecommand>
@duglin
Copy link
Contributor

duglin commented Dec 3, 2015

if we're going to add some kind of conditional logic I would prefer if we made it more feature-rich and add real if-like statements so that the conditions can be based on what's meaningful to the Dockerfile developer and not just what we as Docker devs consider important. Even just simple comparison of env vars would be good enough for lots of uses.

But of course, the Dockerfile syntax is frozen for now :-)

@lowenna
Copy link
Member Author

lowenna commented Dec 3, 2015

@tiborvass Interested in your opinion here too. Thanks.

@lowenna
Copy link
Member Author

lowenna commented Dec 3, 2015

@jfrazelle @mikedougherty as this was thought of in the context of CI flakiness debugging.

@mikedougherty
Copy link
Contributor

@jhowardmsft thanks for the ping. This is interesting! There definitely seems to be a need for this functionality, but something about the boolean/conditional syntax has a bad smell to me. Even sprinkling in ifs as @duglin mentioned also doesn't sound right. My first instinct would be that there should be different Dockerfiles for each arch, but that also seems wrong as it would just result in duplicated Dockerfiles (except for the FROM line) in many cases. Unfortunately I've got no real alternative to offer, so I guess I'll look forward to following this discussion :)

@thaJeztah thaJeztah added area/builder kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny labels Dec 3, 2015
@thaJeztah
Copy link
Member

I think having multiple architectures (the example here looks more related to different operating systems) might become very confusing in a single Dockerfile, especially in cases where windows and linux are mixed. I think so far consensus was to use different Dockerfiles.

Having said that; if only small differences are needed, could we resolve this with build-time args? #15182

@LK4D4
Copy link
Contributor

LK4D4 commented Sep 16, 2016

I'm going to close it because everyone lost interest. Feel free to open again if it's still a problem.

@LK4D4 LK4D4 closed this as completed Sep 16, 2016
@lowenna
Copy link
Member Author

lowenna commented Sep 16, 2016

@LK4D4 Absolutely, right call 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/builder kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny
Projects
None yet
Development

No branches or pull requests

5 participants