Default the BMF version per project

[epompeii]

Each project now carries a bmf_version: the Bencher Metric Format version a report payload is read as when it declares none.

The field

bmf_version is a project field. It starts at 0 for every project, new and existing, so a payload with no key reads as it always has. It is visible to anyone who can see the project. Only a server admin can move it: a PATCH /v0/projects/{project} that carries bmf_version from anyone else is refused, and a PATCH that does not carry it is the patch it has always been for that caller. Nothing ratchets, so an admin can move it back just as easily.

A default, not a ceiling

A payload that declares bmf_version is read at the version it declares, on any project, in either direction. A project at 0 takes an explicit 1 and a project at 1 takes an explicit 0. Only the absent key follows the project. That is what lets a project move from v0 to v1 gradually: an admin flips the default once most of a project's harnesses write v1, and the rest declare 0 until they catch up.

Since #1015 the declared version is a contract over the payload, and the project's default is read through that contract. On a project set to 1, a v0 payload with no key is refused with the contract's 400, because it parses as version 0 and is read as version 1. Every non-JSON adapter parses as version 0, so on such a project those harnesses declare bmf_version: 0.

Where the version is resolved

Report ingest and /v0/run resolve the version once, where the report is created, and everything downstream reads the resolved value. A job based run stores the resolved version on its job config, so the runner's output parses at the version the run was accepted at, whatever the project says by the time the job completes. A config stored before the key still reads as version 0.

Tested

A new project reads back at 0. On a project set to 1, a v1 payload with no key ingests, and it normalizes to the same report as the same payload with null and with an explicit 1; a v0 payload with no key is refused by the contract, naming both versions. An explicit 0 ingests on a project at 1 and an explicit 1 ingests on a project at 0. An admin moves the field both ways. A non-admin carrying the field is refused, and the same patch without the field succeeds. /v0/run with no key follows the project the same way, and a job based run stores the project's version on its config when the key is absent and the declared version when it is present.

[github-actions]

Bencher Report

Project	Bencher
Branch	u/ep/parameters-api/project-gate
Testbed	intel-v1

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
Adapter::Json	📈 view plot 🚷 view threshold	5.26 µs (+10.37%) Baseline: 4.77 µs	5.60 µs (93.90%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold	5.05 µs (+9.22%) Baseline: 4.62 µs	5.37 µs (94.07%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	28.32 µs (+8.51%) Baseline: 26.10 µs	28.36 µs (99.86%)
Adapter::Rust	📈 view plot 🚷 view threshold	4.72 µs (+27.49%) Baseline: 3.71 µs	5.39 µs (87.71%)
Adapter::RustBench	📈 view plot 🚷 view threshold	4.69 µs (+26.59%) Baseline: 3.70 µs	5.38 µs (87.18%)

🐰 View full continuous benchmarking report in Bencher