sqlitecpp-ci-workflows

# SQLiteCpp CI Workflows ## Common steps - Checkout code. - Initialize submodules: `git submodule update --init --recursive`. - Configure build directory (`build` or `builddir`). - Build and run tests with verbose output. ## GitHub Actions (CMake) - Matrix across Windows (MSVC/MinGW), Ubuntu, macOS. - Keep the latest-MSVC Windows build in Debug mode. - Complement it with two Visual Studio 2022 Release builds for Win32/x86: one shared and one static. Do not recreate broader Visual Studio matrices. - Keep the dedicated minimum-MSVC job on `windows-2022`: install the optional VS2017 15.9 / v141 toolset, select it with `-T v141`, and assert MSVC 1916 in the consumer. Run unit tests, the example, and the consumer with standard filesystem and string_view checks. Do not assume a current runner includes this optional toolset or let the baseline job silently use the default compiler. - CMake config includes: - `-DBUILD_SHARED_LIBS=ON` for standard configurations; VS2022 Win32/x86 Release covers both `ON` and `OFF`. - `-DSQLITECPP_BUILD_TESTS=ON` - `-DSQLITECPP_BUILD_EXAMPLES=ON` - `-DSQLITECPP_RUN_CPPCHECK=OFF` - `-DSQLITECPP_RUN_CPPLINT=OFF` - Tests: `ctest --verbose --output-on-failure`. - Keep explicit custom assertion handler coverage in Debug and Release. The `SQLITE_ENABLE_ASSERT_HANDLER` CMake option defaults to `OFF`, so default builds of tests and examples do not compile or link the application-provided handlers. The dedicated static-library job enables this option and builds the unit tests and both examples to check their handler definitions. ## GitHub Actions (Meson) - Use `pipx install meson ninja`. - Set `CC`, `CXX`, and optional linkers. - Setup with tests/examples and sqlite3 fallback: `meson setup builddir -DSQLITECPP_BUILD_TESTS=true -DSQLITECPP_BUILD_EXAMPLES=true --force-fallback-for=sqlite3`. - Build: `meson compile -C builddir`. - Test: `meson test -C builddir`. ## Coverage (Coveralls) The `Coverage` workflow (`.github/workflows/coverage.yml`) builds with `-DSQLITECPP_USE_GCOV=ON` (GCC only), runs `ctest` (both `UnitTests` and `Example1Run`), captures with `lcov` while excluding `/usr`, `googletest`, `sqlite3`, `examples` and `tests`, and uploads to Coveralls. To find which lines are still uncovered without rebuilding locally, query the Coveralls JSON API for the master repo (the build id comes from the repo summary): ```sh # Overall percentage and the latest build id curl -s https://coveralls.io/github/SRombauts/SQLiteCpp.json # covered_percent, badge, build id # Per-file missed counts for a build (source_files is a JSON-encoded string inside the payload) curl -s "https://coveralls.io/builds/<BUILD_ID>/source_files.json?per_page=100" # Exact missed line numbers for one file (array of hit counts; null/0 entries are uncovered) curl -s "https://coveralls.io/builds/<BUILD_ID>/source.json?filename=src/Statement.cpp" ``` Before giving up on a miss, work out the root cause; some look like artifacts but are fixable: - **Multi-line pack expansion** (`(void)std::initializer_list<int>{ ... };` split across lines for variadic `bind`/`execute_many`). When the per-element call can throw, gcov puts the post-call edge on the standalone `initializer_list` line and reports it uncovered even though the calls run. Collapse the expansion onto a single line so gcov attributes it to the tested call expression. - **A guard that looks unreachable** may still be reachable through a public constructor. The `Column` "Statement was destroyed" check is shadowed by `checkRow()` on the normal path, but `Column`'s constructor and `Statement::TStatementPtr` are public, so a test can construct a `Column` from a null pointer directly. Check the public surface before assuming dead code. Genuinely not worth chasing: - **Closing-brace lines** that gcov marks uncovered as exception-unwinding landing pads. These are compiler-version specific (a local gcc may not even reproduce what CI's gcc reports), and removing them means contorting the function. Leave them. - **Platform-specific success paths**, e.g. the normal return of `loadExtension`, which the only portable test cannot reach without a real loadable extension binary. Cover the genuinely reachable lines and leave the rest. ## Sanitizers - The `Quality` workflow already runs separate Clang ASan and UBSan jobs on Ubuntu. - A sanitizer runtime on the link command does not instrument a translation unit. UBSan compile flags must reach the library, unit tests, and examples, including inline API calls. - `SQLITECPP_USE_UBSAN` propagates compile and link options through the SQLiteCpp target. The UBSan CI job verifies every project compile command before building. - Keep `UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1` so a diagnostic fails the job.