@Brendan Hansknecht @Luke Boswell I'm sorry to say I had to revert the sqlite improvements PR on basic-webserver. I tried for more then 3 days but I could not fix the linking error on linux aarch64. The sqlite crate was using sqlite3-sys under the hood so it's strange that the linking no longer works when we are using sqlite3-sys directly.
You're welcome to take a stab at fixing the linking yourself of course, but I'd like to postpone a revert of my revert for basic-webserver 0.11.0 so we have everything ready for AoC
I've seen issues like this myself sometimes in github workflow builds where the bug only shows up in the workflow, it's a big headache (especially once you get to the stage of "troubleshooting via re-running the build, slowly, over and over again"), there's probably a whole class of that category of bug and the only way to reproduce it is to figure out how to run the github action locally and on the right architecture that it's failing on (which is possible, but non-obvious, via tooling... nektos/act
comes to mind, but it too is imperfect)... I now feel like this type of deployment design violates the general dev rule of "dev/build environment must be as similar to prod environment as possible" and in all future cases when I need this I think I will be using something Nix-powered instead (because at the very least it runs exactly the same locally as remotely while building deterministically across different architectures, and also you can just output docker images with high determinism), even though Nix is yet another pain to deal with sometimes (but at least with Nix, I feel like once I figure out how to get Nix to "do the thing," that is a solved problem for all time)
In this case, the key issue was that we have a self-hosted linux aarch64 server but we can't securely share it between multiple github projects, so I can't use it for PR testing on basic-cli
Last updated: Jul 05 2025 at 12:14 UTC