You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was able to build the dockerfile in the /7.5/alpine folder on a Raspberry Pi by modifying FROM: alpine:3.4 to FROM:armhf/alpine:3.5. I've successfully tested a simple application, but how can I be sure the build is stable enough to submit a pull request?
That is correct, the alpine version upgrade was accidental. My goal was to provide a minimal docker container suitable for the Raspberry Pi family of computers, though this should hypothetically work on any armhf/arm7 device. I noticed a concerning number of compile warnings over the course of the build process, so I was hoping to find ways of testing the build for stability.
Addendum: after reading through #298 I will rebuild from armhf/alpine:3.4 to ensure fewer unexpected behaviors. This still leaves the question of how to properly test such a build, any suggestions?
That's fair. On the recommendation of my coworkers, I'll test a set of example apps from public sources to test the build. If they function as expected, can I submit a pull request? Is there any particular folder structure desired or preferred location for the relevant dockerfile?
I think if we'd ever want to offer arm builds we'd want to make sure we have some automated testing setup (maybe via the node.js/build group. Unless at some point Travis-CI offers it :)
To be honest, arm support has not really been on our radar. I'm also not aware of the current support in Docker or the Docker Hub for different architectures.
It would probably be good for someone else to chime in about where things are at and whether us adding ARM support at this time is viable.
Our current stated position in the official-images project is here. We currently build node on arm64, armhf, i386, ppc64le, and s390x using the groovy file here which only changes the FROM and the file pulled by curl.
We are working on making it dead simple to add architectures with some groundwork in docker-library/official-images#2289 and docker-library/go-dockerlibrary#2. We want to make it easy for each image to support multiple architectures without ballooning the work that they do. The hope for the future is that you could just build the same Dockerfile on the right architecture and it will just work.
Closing because docker has plans to handle architecture, but said plan is still in progress. After those plans are released alternate architecture dockerfiles are probably going to be unnecessary, rendering this issue pointless.
Activity
LaurentGoderre commentedon Feb 6, 2017
See #298 for the discussion about upgrading Alpine
chorrell commentedon Feb 6, 2017
I think this issue is actually about providing images for armhf/linux-armv7?
ArunKalahasti commentedon Feb 6, 2017
That is correct, the alpine version upgrade was accidental. My goal was to provide a minimal docker container suitable for the Raspberry Pi family of computers, though this should hypothetically work on any armhf/arm7 device. I noticed a concerning number of compile warnings over the course of the build process, so I was hoping to find ways of testing the build for stability.
ArunKalahasti commentedon Feb 6, 2017
Addendum: after reading through #298 I will rebuild from armhf/alpine:3.4 to ensure fewer unexpected behaviors. This still leaves the question of how to properly test such a build, any suggestions?
chorrell commentedon Feb 6, 2017
Sorry, I don't have any suggestions.
The Node.js build group does build and test on ARM though:
https://ci.nodejs.org/computer/
https://ci.nodejs.org
That doesn't speak to whether your code/modules will work though.
ArunKalahasti commentedon Feb 6, 2017
That's fair. On the recommendation of my coworkers, I'll test a set of example apps from public sources to test the build. If they function as expected, can I submit a pull request? Is there any particular folder structure desired or preferred location for the relevant dockerfile?
chorrell commentedon Feb 6, 2017
I think if we'd ever want to offer arm builds we'd want to make sure we have some automated testing setup (maybe via the node.js/build group. Unless at some point Travis-CI offers it :)
To be honest, arm support has not really been on our radar. I'm also not aware of the current support in Docker or the Docker Hub for different architectures.
It would probably be good for someone else to chime in about where things are at and whether us adding ARM support at this time is viable.
LaurentGoderre commentedon Feb 6, 2017
In theory, you could change this line https://github.com/nodejs/docker-node/blob/master/7.5/alpine/Dockerfile#L39 to
make install && make testto run the v8 tests. Haven't tested this though. From what Isee from the CI, the tests are long! More than 5 hoursyosifkit commentedon Feb 6, 2017
Our current stated position in the official-images project is here. We currently build node on arm64, armhf, i386, ppc64le, and s390x using the groovy file here which only changes the
FROMand the file pulled bycurl.We are working on making it dead simple to add architectures with some groundwork in docker-library/official-images#2289 and docker-library/go-dockerlibrary#2. We want to make it easy for each image to support multiple architectures without ballooning the work that they do. The hope for the future is that you could just build the same Dockerfile on the right architecture and it will just work.
ArunKalahasti commentedon Feb 24, 2017
Closing because docker has plans to handle architecture, but said plan is still in progress. After those plans are released alternate architecture dockerfiles are probably going to be unnecessary, rendering this issue pointless.