In theory (!) it should be pretty easy to just copy the above code snippet into your unit testing setup, which would also reduce the line count of C code in your repo. :)
In the above code I'd probably use "make -j `nproc`" instead of the hard coded number of cpus (-j2) though, so it automatically uses however many are available. Should probably update that. :)
That looks great, thanks for sharing! Given that the zig build system uses zig and zig just got an http client in the standard library, I think it would be feasible to port into stanchion's build. Out of curiosity, do you run unit tests locally using a container that is set up from the CI config you linked (using something like `act`)? Or do you just require sqlite to be installed when you run locally?
Most of those are oriented around building packages for various OS's (Linux, macOS, Windows) so people can try the latest code.
While there are some tests, they're more like extremely basic sanity checks and they don't use containers.
Those tests rely on whichever version of SQLite was downloaded and compiled into the GUI (as per above code snippet).
---
That being said, that's for the client side GUI application. There's a server side of things too (https://github.com/sqlitebrowser/dbhub.io -> dbhub.io) that does use containers (docker) for it's automated tests:
Those are integration tests though (eg "make sure we didn't bust communication with our cli", "make sure our go library still works 100% with the server"), and a reasonably decent set of End to End (E2E) tests of the web interface using Cypress.
EDIT: nvm, the github stats seem to be completely wrong? It shows 96% C to me...
Found it, I believe this is the result of including code from SQLite in the repo