ワンクリックで
sqlitecpp-ci-workflows
SQLiteCpp CI workflow patterns. Use for GitHub Actions, AppVeyor, Travis, matrices, or test steps.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
SQLiteCpp CI workflow patterns. Use for GitHub Actions, AppVeyor, Travis, matrices, or test steps.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Running shell commands on this Windows checkout via the PowerShell and Bash tools, and passing multi-line or quoted arguments (commit messages, PR bodies, file content) without corruption. Use when running git or gh with multi-line or quoted input, writing a commit message or PR body from the command line, reaching for a heredoc or here-string, or after a message or body comes out wrapped in stray characters such as a leading and trailing `@`.
SQLiteCpp change workflow checklists for API, tests, build files, and CHANGELOG updates. Use when adding a method or class, editing build files, or writing a CHANGELOG entry for a PR.
SQLiteCpp coding standards and API rules for core edits, public headers, style, and Doxygen.
Default response behavior for AI coding agents: professional, factual, neutral tone with calibrated critical evaluation. Baseline for every task: implementation, code review, debugging, planning, research, evaluation, Q&A.
Editing conventions for files under `.claude/skills/**` (markdown style, frontmatter format, SKILL.md vs `references/` split, upstream-vendored skills). Use when creating a new skill, editing any `SKILL.md` or `references/*.md` file, refactoring a skill description, or after adding/removing a skill.
SQLiteCpp branch naming and creation rules for starting tasks, issues, or features.
| name | sqlitecpp-ci-workflows |
| description | SQLiteCpp CI workflow patterns. Use for GitHub Actions, AppVeyor, Travis, matrices, or test steps. |
git submodule update --init --recursive.build or builddir).-DBUILD_SHARED_LIBS=ON-DSQLITECPP_BUILD_TESTS=ON-DSQLITECPP_BUILD_EXAMPLES=ON-DSQLITECPP_RUN_CPPCHECK=OFF-DSQLITECPP_RUN_CPPLINT=OFFctest --verbose --output-on-failure.pipx install meson ninja.CC, CXX, and optional linkers.meson setup builddir -DSQLITECPP_BUILD_TESTS=true -DSQLITECPP_BUILD_EXAMPLES=true --force-fallback-for=sqlite3.meson compile -C builddir.meson test -C builddir.-DSQLITECPP_BUILD_EXAMPLES=ON -DSQLITECPP_BUILD_TESTS=ON -DSQLITECPP_RUN_CPPCHECK=OFF.ctest --output-on-failure.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):
# 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:
(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.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:
loadExtension, which the only
portable test cannot reach without a real loadable extension binary.Cover the genuinely reachable lines and leave the rest.