Tag
releases
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 …
releases
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 …
guides
jvq flaky needs two things from your CI: test results it can read, and a history file that survives from one run to the next. Everything else is optional. These are the …
releases
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 …
case studies
The fastest way to find out what a flaky test gate does with real failures is to give it some. jvq has its own CI history on GitHub: 26 pushes to main between October 18 …
testing
The first round of tests ran jvq hundreds of times on a Go benchmark whose cost we set by hand. That showed how often it raises a false alarm and how often it catches a …
releases
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 …
case studies
An access logger writes one JSON line per request. In Go, the usual way to make that cheap is to append into a buffer the caller owns: no fmt, no encoding/json, no …
case studies
A log pipeline pulls query parameters out of request paths, millions of times a day. The function that does it is eight lines of hand-written splitting. It’s fast, …
case studies
Some tools are judged by their size. A small binary that gets copied onto every build agent, baked into container images, or downloaded at the start of each CI job pays …
releases
The first jvq release read one thing: the output of Go’s go test -bench. That covered Go projects and nothing else. Version 0.2 drops the limit. If your benchmark …
releases
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 …
releases
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 …
releases
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 …
testing
A gate that blocks merges has two ways to fail. It can cry wolf, flagging changes that did nothing, until people stop trusting it. Or it can sleep through a real …
explainers
A performance budget is a promise written into the pipeline: this change may make the code at most 5% slower, and if it’s worse, the build fails. Tests already …
the name
jvq stands for just very quickly. It’s what you say when someone asks whether a change will slow things down. “It only adds a check, it’ll run just very …