3 ms·

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 feas

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?

justinclift 3y ago
We have a spread of different GitHub Actions based workflows that do stuff whenever a PR is proposed or merged: https://github.com/sqlitebrowser/sqlitebrowser/tree/master/.github/workflows https://github.com/sqlitebrowser/sqlitebrowser/tree/master/.... 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 https://github.com/sqlitebrowser/dbhub.io -> dbhub.io) that does use containers (docker) for it's automated tests: https://github.com/sqlitebrowser/dbhub.io/tree/master/.github/workflows https://github.com/sqlitebrowser/dbhub.io/tree/master/.githu... 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. --- Does that help? :)