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

Add platform flag to build #217

Merged
merged 1 commit into from
Apr 4, 2019
Merged

Add platform flag to build #217

merged 1 commit into from
Apr 4, 2019

Conversation

hlxid
Copy link
Contributor

@hlxid hlxid commented Feb 16, 2019

Adds the platform flag to build which allows building multiarch images by passing a comma separated list of platforms to it.

@codecov
Copy link

codecov bot commented Feb 16, 2019

Codecov Report

Merging #217 into master will not change coverage.
The diff coverage is 0%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master   #217   +/-   ##
=====================================
  Coverage       0%     0%           
=====================================
  Files          14     14           
  Lines         777    782    +5     
=====================================
- Misses        777    782    +5
Impacted Files Coverage Δ
build.go 0% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1bed545...6fe9043. Read the comment docs.

@AkihiroSuda
Copy link
Collaborator

@tonistiigi PTAL?

@tonistiigi
Copy link

Using any platform from request as a supported one in the controller seems to counter buildkit design of preventing user from doing wrong things. If the use case for that part is to use qemu(and there is no good other place to put it) then we could do quite a lot with autodetection. Might want to change the flag to stringslice as well (or support both).

@hlxid
Copy link
Contributor Author

hlxid commented Feb 26, 2019

The intended use case is for qemu and binfmt yes. How would such autodetection be done? I wanted to ask that in the pr message but forgot. Checking all registered formats for binfmt at /proc/sys/fs/binfmt_misc is possible on an actual host but not in an container.

@tonistiigi
Copy link

@Dani909 moby/buildkit#840

@hlxid
Copy link
Contributor Author

hlxid commented Feb 28, 2019

Thanks. Will integrate once merged and released.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

Found some fixes!

P.S. share your ideas, feedbacks or issues with us at https://github.com/fixmie/feedback (this message will be removed after the beta stage).

@hlxid
Copy link
Contributor Author

hlxid commented Apr 2, 2019

@AkihiroSuda @tonistiigi PTAL

@AkihiroSuda
Copy link
Collaborator

looks good, but needs go mod vendor

@hlxid
Copy link
Contributor Author

hlxid commented Apr 3, 2019

now it's vendored

@jessfraz
Copy link
Collaborator

jessfraz commented Apr 4, 2019

thanks!!!

@jessfraz jessfraz merged commit 013bb21 into genuinetools:master Apr 4, 2019
cirocosta pushed a commit to cirocosta/builder-task that referenced this pull request May 20, 2019
with the introduction of the `platform` flag to `img`, we're now able to
set what's the base platform that the images that we `FROM` should use.

(see genuinetools/img#217)

this allows one that has `FROM ubuntu:bionic` to use an armv7-based base
image when running with `--platform=arm`, and an arm64 when using
`--platform=arm64`.

Signed-off-by: Ciro S. Costa <cscosta@pivotal.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants