Yarn installation succeeds locally, fails on resin.io

Product support
1

Hi,

I’ve got a strange problem when trying to build my application on resin.io. As part of the installation process I invoke Yarn, an alternative client for NPM, to install some packages. My setup is a little strange because Yarn hits a private NPM repository which runs in the background (accessible on localhost). However, it has been working well when deployed via rdt push. Today I tried testing on resin.io and when the image build got to the step involving yarn it just hung:

[Build]    yarn global v0.20.0
[Build]    [1/4] Resolving packages...
[Build]    verbose Performing "GET" request to "http://localhost:13337/my-secret-package".
[Build]    <snipped log output from private registry process indicating request was served>
[Info]     Still working...
[Info]     Still working...
[Info]     Still working...

Yarn retries the request a couple times and then errors out. In my debugging I found out that os.networkInterfaces() fails with an error that has the “syscall” attribute set to uv_interface_addresses. This turned out to not be the problem but it made me suspect that there might be other differences between the docker build environment/invocation on resin.io and locally on my device.

So I have two questions:

  1. Is there an easy/known answer for why this fails on resin.io but not via rdt push? Maybe the configuration necessary for setting up cross-compilation also changes how the network looks during the build?
  2. Could you kindly point me to where in the ResinOS codebase the docker build invocation triggered by rdt push lives? This issue is probably due to something in the specifics of my approach so I’d be happy to track it down myself but I’m finding it a little daunting to trace the execution path across the ResinOS codebases.
2

I found the problem and a fix. The likely thing was the reality - my code was at fault and not Yarn’s. Ironically the suspect section that I found in Yarn’s codebase was addressing exactly the problem that I failed to address in my own private registry codebase. It was using os.networkingInterfaces() to figure out the hostname. Since that was failing at uv_interface_addresses the hostname was not being correctly determined so it would get the request but reply with metadata containing bogus links. Hardcoding the hostname to 127.0.0.1 when building on resin.io fixes the issue and lets the image build complete.

Though changing my code fixed the problem the behavior violates an assumption that I had: image builds on ResinOS and resin.io would behave the same from the perspective of my code. So learning more about how builds happen on resin.io would help me prevent problems like this in the future.

Is there detailed documentation of the resin.io build process somewhere? I found docs here and here but they don’t go into the details that would have let me avoid this.

3

jmptable,

There are no more detailed docs than the ones you’ve linked to, that I’m aware of. I’m actually surprised that the builders alter this behavior, and I’ll open an issue with the builder team to get this sorted out somehow (either bringing the builders in-line with a standard Docker build or documenting the differences clearly).

4

I just went to file this issue, only to discover our CTO reported it recently, and the fix is currently being deployed to our staging environment. It should hit production in the next couple of business days, depending on how the evaluation on staging goes.

5

Thanks, that’s great. I’ll revisit and test at the end of next week.