-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[buildx/arm64] yarn and npm not able to download packages from internet #1335
Comments
ARe you sure your docker is correctly configured to allow internet access to your containers? |
Hi @LaurentGoderre , As I wrote, the same holds true for running in GitHub Action environments. I already had this idea, so I verified the issue by running the build on other platforms. Also, in every environment amd64 builds just fine. What do you think I can further do, to help with this issue? Thanks and best regards |
@PeterDaveHello I noticed you added the yarn label to this issue. I also checked this using npm with the exact same behavior as yarn. Currently I am trying to run some network diagnostic inside the container. If I stumble upon something useful, I will let you know. best regards |
I think this is fairly reproducible. On my ubuntu machines, any I am not able to reproduce however on my macbooks. |
Let me guess – you're not building on an actual arm64 runner node which means the arm64 build is generated using QEMU. Emulation is slow, therefore there's much higher risk of running into timeouts. It may be still possible there's an additional problem with the network connection which may be worth debugging (I do see |
While this seems plausible, I think it's the common case that projects will build against an emulated environment. Would it not be an improvement to |
I'm having similar problem. I have also started a SO thread |
got the same issue on arm instance to build amd64 image with emulator |
It also stuck in |
There is an issues with Node v19+ and arm based images. It is described in nodejs/docker-node#1794 and nodejs/docker-node#1335. At this moment it works with v18 based images and so I downgraded to it.
There is an issues with Node v19+ and arm based images. It is described in nodejs/docker-node#1794 and nodejs/docker-node#1335. At this moment it works with v18 based images and so I downgraded to it.
Same here. Less than a minute locally vs. 8 minutes on average running in a Docker build step on GitHub Actions. I confirm we are building an Also, no way to get it working without using |
@mohsenasm I agree with you. Look's like this effects |
I would have NEVER imagined such a difference in build time on a Xeon V4 server: amd64
arm64 w/ QEMU
This is (or should be) unacceptable for any standards. One way to approach this is by splitting into build stages, where the npm install and build are done only on native auth and the final image is only created with multi arch |
Yes I also faced this issue while building multi platform image. The only solution currently I found in my fit is that you create docker image seperately and create multi platform manifest on anyone machine. With parallel building these two image and then combining them will give you better results. |
Thought this was multiplatform build issue but Docker on Rapsberry Pi 4 , native aarch64/arm64, has same problem with node 20.12.0. With node 18,20,0 build never seems to finish or fails. In all these cases I used But |
Just to double-check, are you using the newer 64-bit Raspberry Pi OS (as opposed to the older 32-bit versions)? |
Actually, tt was Ubuntu 22.04.3 LTS 64-bit on Raspberry Pi. |
People on node 20 with npm 10 could try downgrading npm to v9 because v10 has a known bug where it opens an excessive amount of network connections, see npm/cli#7072. |
Try to use node:lts-alpine3.20 as base image for NodeJS 20 (current LTS version) Something like
And github actions buildx setup with platforms that required:
Build for both platforms takes like 2 minutes |
As per nodejs/docker-node#1335, cross-platform build using QEMU and Buildx is very slow. Also we do not require multi-arch image for now Signed-off-by: Muhammad Naufal <me@falkia34.dev>
After many tests, I have now discovered that there is currently a problem with node and arm64 in GitHub workflows. There is the following issue: nodejs/docker-node#1335. As already mentioned at the top of the Node.js issue, a possible solution would be to run it in offline mode, i.e. to cache the packages. I have now adapted the GitHub workflow file so that it already works. As you have already correctly noted, I have added QEMU. Since this problem only affects Node, the backend is not affected and already has the multi-architecture variant. To give the frontend multi-arch as well, you would only have to add `linux/arm64` to the platform, and then it should also work there. But I still have a question: Why do you not work with the versions in the workflow file, but with special commits? --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Works fine (although pretty slow) for node 20.12, fails miserably with 20.16 |
Ok, something is broken from node 20.13 and later. |
Timeout to 100000 kinda helped against the error, but the speed... it took 1 hour to deploy.. |
Hi there,
thanks for your awesome work with this project. I am experiencing issues using buildx for the arm64 arch. Everything is running smooth until yarn or npm is trying to download packages over the network.
This is an snipped from build-log running on GitHub actions while using yarn:
Running the same buildx build locally the output is a bit more concise:
The command used to start the build:
docker buildx build --platform linux/amd64,linux/arm64 -t myrepo/myproject:latest --push client/
My Dockerfile looks like this:
(Note that I do not copy node_modules into build context. The files to copy are managed using a
.dockerignore
file.)Workaround
As a workaround I currently using a .yarnrc to create an offline cache. I copy a it into the build context and install it with the
yarn --offline
option. That works for now, but I do not like it very much. https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/thank you again and best regards
The text was updated successfully, but these errors were encountered: