The solution ended up being yarn install --network-timeout 600000 to change the default build timeout. This is when using Node’s own containers: node:14.17.0-alpine3.13.
Adding here for others to find if they experience the issues, and also to throw some ideas around on a potential fix.
What might help, is if the CLI had an option to build one container at a time. When I do a local deploy, it tries to build all my containers simultaneously, which on a SD card is a big ask.
If the Balena -build images had a higher timeout by default. This wouldn’t of prevented the issue for me on this occasion, as I am using the official Node images because of all the gaps in the Balena image database, but could prevent the issue in the future.
On a more targeted note, perhaps review why the Balena wifi-connect UI is such a cumbersome build process. Perhaps it just needs the packages updated.
Nice troubleshooting and analysis here @maggie0002 !
That CLI option is a good idea, I’ll open a GitHub Issue for that to be evaluated.
As for WiFi Connect, the biggest issue there is that it does not currently have a maintainer / code owner. So, it could probably use some updating and TLC. If you or anyone else in the community would like to adopt it, I know we’d be very grateful!
That’s good to know, I was wondering what was happening with wifi connect. It hasn’t had much love for a while, I had figured it may be merged into the OS eventually. Is the plan for it to be primarily community maintained from now on?
One of the challenges is it’s written in Rust, which will probably be harder to find maintainers for (the UI is easier to maintain, but I assume you were referring to the whole thing rather than just the UI). That and of course it’s complexity. On the more positive side, it’s already pretty solid, and wouldn’t need too much work.
I don’t think there is a specific plan to merge it into the OS, at least not that I am aware of anyways. As for community maintenance, yes it would all need to be adopted, but, that could be more than one person. So as an example, if you are strong on the UI side but happen to know someone who is strong in Rust, then that would be just fine. (Also not saying it needs to be you, ha, just making the point that multiple users maintaining is fine).
Well, I will have a look through the issues on the GitHub repo and try and pull out what issues are coming up most. I think most of them are support issues, or low priority feature requests. There would probably only be a few that come up regularly enough/are priority enough to need any action. I’m sure it won’t please everyone, but keeping the ambition low is far more sustainable, and it really is a solid app already.
Will look to you on where best to continue the discussion, perhaps a new thread specifically on this to try and attract contributions?
@maggie0002 thanks for the detailed notes here! I’ll give them a more thorough read in a moment, but I am thinking we may want to split them off into a new thread, like you mentioned. Let me figure out the best way to accomplish that.
