Releases on JVQ.net

Releases on JVQ.net https://jvq.net/tags/releases/ Recent content in Releases on JVQ.net Hugo en-us Wed, 04 Nov 2026 00:00:00 +0000 jvq Flaky Now Takes Three Lines of YAML and Shows the Tests a Crash Skipped https://jvq.net/jvq-flaky-now-takes-three-lines-of-yaml-and-shows-the-tests-a-crash-skipped/ Wed, 04 Nov 2026 00:00:00 +0000 https://jvq.net/jvq-flaky-now-takes-three-lines-of-yaml-and-shows-the-tests-a-crash-skipped/ <p>The flaky test gate in 0.7 worked, but setting it up in GitHub Actions meant copying fifteen lines of YAML: restore a cache, pick the right flag for pull requests, run the gate, save the cache, but only on the main branch. Most people who’d want it would read that block and decide to do it later.</p> <p>Version 0.8.0 puts all of that in the action:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span> - <span style="color:#f92672">run</span>: <span style="color:#ae81ff">go test -json ./... > go-test.json || true</span> </span></span><span style="display:flex;"><span> - <span style="color:#f92672">uses</span>: <span style="color:#ae81ff">just-very-quickly/jvq@v0.8.0</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">with</span>: </span></span><span style="display:flex;"><span> <span style="color:#f92672">flaky</span>: <span style="color:#ae81ff">go-test.json</span> </span></span></code></pre></div><p>The action installs jvq and keeps the test history in the Actions cache. Pushes to your default branch add to it, and so do manual and scheduled runs there. Pull requests are judged against it without writing, so a branch full of half-finished work can’t teach the gate that a broken test is flaky. Each job of a matrix keeps its own history, because a test that fails on one Go version and passes on another isn’t flaky, it’s broken on one of them.</p> jvq Shrinks Its Flaky Test History 80 Times and Lets You Pin Tests In or Out of Quarantine https://jvq.net/jvq-shrinks-its-flaky-test-history-80-times-and-lets-you-pin-tests-in-or-out-of-quarantine/ Wed, 04 Nov 2026 00:00:00 +0000 https://jvq.net/jvq-shrinks-its-flaky-test-history-80-times-and-lets-you-pin-tests-in-or-out-of-quarantine/ <p>The flaky test gate keeps one line per CI run, and through 0.8 that line spelled out every test’s name. Fine for a few hundred tests. For a suite of 2000 Go tests with long package paths, 200 runs came to 26.8 MB, and that file goes in and out of the Actions cache on every job.</p> <p>Version 0.9.0 writes each name once. The file starts and ends with the list of test names, and a run’s line says which numbers passed, failed or were skipped:</p> jvq Quarantines Flaky Tests So They Stop Blocking Merges https://jvq.net/jvq-quarantines-flaky-tests-so-they-stop-blocking-merges/ Sat, 31 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-quarantines-flaky-tests-so-they-stop-blocking-merges/ <p>Every team has a test like this. It checks out a cart, or uploads a file, or waits on a socket, and about one run in ten it fails for no reason anyone can find. The pull request goes red. Somebody clicks “re-run” and it goes green. After a few weeks everyone clicks re-run without reading the failure, and one day the failure is real.</p> <p>Version 0.7.0 adds a second gate to jvq for this. <code>jvq flaky</code> reads your test results, keeps a small history across CI runs, and tells two kinds of failure apart: a test that fails on code that also passed it, and a test that fails because the code broke.</p> jvq 0.5 Keeps a History to Catch the Slowdown That Arrives One Small Merge at a Time https://jvq.net/jvq-0.5-keeps-a-history-to-catch-the-slowdown-that-arrives-one-small-merge-at-a-time/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-0.5-keeps-a-history-to-catch-the-slowdown-that-arrives-one-small-merge-at-a-time/ <p>A budget gate has a blind spot, and it’s built in. jvq judges each change against its base. A change that makes a benchmark 1% slower passes a 5% budget, and it should. So does the next one. Ten merges later the code is about 10% slower, and every check said pass.</p> <p>Version 0.5 keeps a history so that kind of creep can show. Each run on the default branch adds a line to a small file. <code>jvq history</code> reads it back: how far each benchmark has moved in all, with an interval, how many runs called it a regression, and a row of blocks with its change run by run.</p> jvq 0.6 Counts Instructions Under Valgrind to Catch a 2 Percent Slowdown on a Noisy Runner https://jvq.net/jvq-0.6-counts-instructions-under-valgrind-to-catch-a-2-percent-slowdown-on-a-noisy-runner/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-0.6-counts-instructions-under-valgrind-to-catch-a-2-percent-slowdown-on-a-noisy-runner/ <p>Time is a noisy thing to gate on. On our 2-core test machine the same benchmark spreads 7 to 9% from run to run, so jvq’s default budget is 5%, and a 2% slowdown walks straight through. It should, given the noise. But 2% is real, and a dozen of them add up.</p> <p>Version 0.6 has a second way to measure. The <code>instructions</code> adapter runs the benchmark under valgrind’s cachegrind and counts every instruction it executes. A count doesn’t care how busy the machine is. Run the same program twice and you get nearly the same number, so the budget can drop to 1%.</p> jvq Now Gates Benchmarks in Any Language, by Timing a Command or Reading a Few Lines of JSON https://jvq.net/jvq-now-gates-benchmarks-in-any-language-by-timing-a-command-or-reading-a-few-lines-of-json/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-now-gates-benchmarks-in-any-language-by-timing-a-command-or-reading-a-few-lines-of-json/ <p>The first jvq release read one thing: the output of Go’s <code>go test -bench</code>. That covered Go projects and nothing else. Version 0.2 drops the limit. If your benchmark is a Python script, a Node program, a shell loop or a compiled binary in any language, jvq can now gate it.</p> <p>There are two new ways in. The <code>time</code> adapter times the whole command, from start to exit, so there’s nothing to change in your code. The <code>json</code> adapter reads results your benchmark prints, one per line, with a name, a unit and a value. Pick one with a line in jvq.toml or <code>-adapter</code> on the command line.</p> jvq Now Gates GitLab Merge Requests, With a Ready Template and a JUnit Report https://jvq.net/jvq-now-gates-gitlab-merge-requests-with-a-ready-template-and-a-junit-report/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-now-gates-gitlab-merge-requests-with-a-ready-template-and-a-junit-report/ <p>Until now jvq came with a GitHub Action and a line in the README saying GitLab works the same way. It did, if you worked out the base commit, the clone depth and the download yourself. Version 0.4 does that part for you.</p> <p>There’s a ready job to include, jvq reads GitLab’s own merge request variables to pick the base, and a new JUnit report puts the result in the merge request’s test summary, next to your other tests.</p> jvq Now Reads criterion, Google Benchmark, pytest-benchmark and vitest as They Are, and Gates File Sizes https://jvq.net/jvq-now-reads-criterion-google-benchmark-pytest-benchmark-and-vitest-as-they-are-and-gates-file-sizes/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-now-reads-criterion-google-benchmark-pytest-benchmark-and-vitest-as-they-are-and-gates-file-sizes/ <p>Version 0.2 let jvq gate a benchmark in any language, by timing the whole command or reading a few lines of JSON. That still meant a little glue for projects that already have a benchmark harness. Version 0.3 removes the glue for four of the most used ones. Point jvq at the harness and it reads the harness’s own output.</p> <p>It also adds a second kind of budget. Besides time, bytes and allocations, jvq can now fail a pull request that makes a file it builds bigger than it should be.</p> jvqq Runs jq Filters on Every Core and Is Tested Against jq Byte for Byte https://jvq.net/jvqq-runs-jq-filters-on-every-core-and-is-tested-against-jq-byte-for-byte/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvqq-runs-jq-filters-on-every-core-and-is-tested-against-jq-byte-for-byte/ <p>Application logs tend to end up in the same shape: a file of a few gigabytes with one JSON event per line, and a question about it. How many 500s per service since the deploy? Which requests hit the timeout? jq answers that kind of question well. On a big file it takes its time, because it reads on one core.</p> <p>jvqq 0.1 is a command-line tool that takes the same filters and runs them on every core. The output comes out in input order and is what jq would print, down to the byte. On a four-core GitHub-hosted runner, seven filters over 1 GiB of logs took 0.7 to 1.8 seconds each with jvqq and 17 to 35 seconds with jq.</p> First jvq Release Fails Pull Requests That Make Go Benchmarks Slower Than Their Budget https://jvq.net/first-jvq-release-fails-pull-requests-that-make-go-benchmarks-slower-than-their-budget/ Sun, 18 Oct 2026 00:00:00 +0000 https://jvq.net/first-jvq-release-fails-pull-requests-that-make-go-benchmarks-slower-than-their-budget/ <p>Most slowdowns get in one pull request at a time. An extra allocation in a loop, a string copied where a slice would do, a log call on the hot path. Each costs a few percent, each passes review, and a month later the service is 30% slower and nobody can say which change did it.</p> <p>jvq 0.1 is a check you put in CI to stop that. You give it a benchmark command and a budget, such as 5% slower at most. On every pull request it runs your benchmarks on the base branch and on the change, on the same runner, taking turns, and fails the build when the change is clearly over budget.</p>