Continuous-testing failure-issue primitive + nightly fuzz job - #1783
Conversation
Version-Control Performance CeilingsRuns: median of 3 executions per benchmark, excluding fixture setup. The
|
Introduce a reusable pattern for scheduled test jobs that should be silent when they pass and cut a GitHub issue when they fail: - .github/actions/report-failure-issue: a composite action that, given a label/title/body, keeps one open tracking issue per label -- creates it if none is open, otherwise comments -- and stamps in the run URL, commit, and workflow. Callers invoke it from an `if: failure()` step. GitHub's own watcher notifications are the email path, so no mail infra is needed. Mirrors the existing sqlite-upstream-drift issue handling, factored out so future continuous jobs reuse it in one step. - .github/workflows/nightly-fuzz: first consumer. Fans the five on-disk deserializer libFuzzer harnesses out into a parallel matrix so each gets its own multi-hour budget (a single job caps at GitHub's 6h limit, so they can't be serialized), running 4h per target by default (configurable via dispatch). The discovered corpus is cached per target so each night compounds on earlier runs instead of restarting from the committed seeds. On a crash it uploads the reproducers and files a per-target fuzz-crash-<target> issue via the action, then fails that leg. Build/run steps match the per-PR smoke job. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sysbench-Style Benchmark (composite PK): Doltlite vs SQLiteCompanion to the classic Sysbench-Style Benchmark. Every workload here In-MemoryReads
Writes
File-BackedReads
Writes
File-Backed (autocommit)Each statement runs as its own transaction — exposes per-commit ReadsReads have no commit cost; these are the same SQL files as the
Writes
100000 rows, median of 5 invocations per test; autocommit writes use 9, workload-only timing via host monotonic clock when available. Performance Ceiling Check (2.5x individual, 2x average; autocommit writes: 10x / 5x)All tests within ceilings. |
Sysbench-Style Benchmark: Doltlite vs SQLiteIn-MemoryReads
Writes
File-BackedReads
Writes
File-Backed (autocommit)Each statement runs as its own transaction — exposes per-commit ReadsReads have no commit cost; these are the same SQL files as the
Writes
100000 rows, median of 5 invocations per test; autocommit writes use 9, workload-only timing via host monotonic clock when available. Performance Ceiling Check (2.5x individual, 2x average; autocommit writes: 10x / 5x)All tests within ceilings. |
Sysbench-Style Benchmark (BLOB PK): Doltlite vs SQLiteCompanion to the classic Sysbench-Style Benchmark. Every workload here In-MemoryReads
Writes
File-BackedReads
Writes
File-Backed (autocommit)Each statement runs as its own transaction — exposes per-commit ReadsReads have no commit cost; these are the same SQL files as the
Writes
100000 rows, median of 5 invocations per test; autocommit writes use 9, workload-only timing via host monotonic clock when available. Performance Ceiling Check (2.5x individual, 2x average; autocommit writes: 10x / 5x)All tests within ceilings. |
Sysbench-Style Benchmark (TEXT PK): Doltlite vs SQLiteCompanion to the classic Sysbench-Style Benchmark. Every workload here In-MemoryReads
Writes
File-BackedReads
Writes
File-Backed (autocommit)Each statement runs as its own transaction — exposes per-commit ReadsReads have no commit cost; these are the same SQL files as the
Writes
100000 rows, median of 5 invocations per test; autocommit writes use 9, workload-only timing via host monotonic clock when available. Performance Ceiling Check (2.5x individual, 2x average; autocommit writes: 10x / 5x)All tests within ceilings. |
What
Sets up a reusable pattern for continuous (scheduled) test jobs that stay silent when they pass and cut a GitHub issue when they fail — no email infra required (GitHub's watcher notifications are the email path). Two pieces:
1.
.github/actions/report-failure-issue(the reusable primitive)A composite action that keeps one open tracking issue per label: it creates the issue if none is open, otherwise comments on it, so repeated failures append to a single triage thread instead of spamming. It auto-stamps the run URL, commit, ref, and workflow name into the body. It never auto-closes — a human closes after fixing.
Any future continuous job wires it up in one step:
This is the
sqlite-upstream-driftissue handling, factored out and generalized.2.
.github/workflows/nightly-fuzz.yml(first consumer)Runs the five on-disk-format libFuzzer harnesses — WAL replay, prolly node, refs blob, chunk index, catalog — for 10 min each nightly (07:00 UTC; duration configurable via
workflow_dispatch). This is the "make fuzzing continuous" item: the harnesses already existed and ran 1 min/target per-PR insmoke.yml; this gives them sustained nightly runtime.fuzz-crashesartifact, files afuzz-crashissue (with per-target ASan logs + base64 reproducers, and thebash test/run_fuzz.sh <target> <file>repro command), then fails the job.smoke.ymlfuzz job.Testing
failedlist, per-target reproducers land via-artifact_prefix, and the issue body composes correctly (madebase64portable via stdin redirect so it works on any runner).smoke.yml, which passes on the Linux CI runners.Note: the schedule only starts running once this is on the default branch; use the Run workflow button (
workflow_dispatch) to trigger it on demand.🤖 Generated with Claude Code