ci: the lint gate cannot pass — Cargo.toml is a tracked public-benchmark input, so every merge train invalidates it (red on main; merged PRs are red too) #10799

Summary

lint is red on untouched main, and it is red for a reason that cannot be cleared: Cargo.toml is a tracked input of the public benchmark baseline, and every merge train's release commit bumps the version in it.

Verified on a clean checkout of main 1a4fa6507 (v0.5.1617), no local modifications:

$ python3 benchmarks/ci_public_baseline_check.py
public baseline error: public artifact benchmark inputs changed; regenerate it with ./benchmarks/run_public_baseline.sh
$ echo $?
2

Root cause

benchmarks/public_baseline.py:34:

SOURCE_PATHS = (
    "Cargo.toml",
    "benchmarks/suite/*.ts",
    ...
)

validate_public compares freshness.source_fingerprint recorded in benchmarks/results/public-node-bun-v1.json against tracked_fingerprint(SOURCE_PATHS).

That artifact was generated 2026-09-01. Since then, of the tracked inputs:

The workspace version lives in Cargo.toml, so every release commit changes the fingerprint. Regenerating costs a ~2-hour quiet-host run (policy.quiet_host plus pinned per-runtime versions), and the very next merge train invalidates it again. There is no state in which this gate is green for more than one train.

Why this matters more than one red check

lint is red on every open PR, and — the part that makes it corrosive — it is equally red on PRs that merged. #10789, #10785 and #10781 all show the same triple lint, e2e-scoped, pr-gate and all three are in main. The train merges straight through.

So three checks are permanently red, carry no signal, and train everyone to ignore them as a block. Anything they would legitimately catch is now invisible. (I lost time myself concluding a PR was blocked by this before checking whether merged PRs showed the same failures — they do.)

Several lanes have already hit it and worked around it in their own evidence rather than fixing it: benchmarks/native_property_get/evidence/base-gate-comparison.json literally records the string under a key named public_freshness_base, and there are *fingerprint* / *public-freshness* artifacts in at least four benchmark trees.

Suggested fix

Cargo.toml is in SOURCE_PATHS to catch dependency/profile changes that could alter what is measured — but the version field cannot. Options, cheapest first:

1. Fingerprint Cargo.toml with the version field normalised out (or hash only [profile.*], [workspace.dependencies] and feature tables). Keeps the real signal, drops the one field that changes every release.
2. Move the version bump out of the fingerprinted file.
3. Drop Cargo.toml from SOURCE_PATHS and rely on HARNESS_PATHS + the recorded toolchain versions.

(1) matches the precedent already in the file: #7282 narrowed HARNESS_PATHS for exactly this reason — "the large shell/Python drivers are plumbing … must not demand a two-hour rerun" — and added an explicit digest migration so the bookkeeping change did not itself force a regeneration. The same migration mechanism (_SOURCE_FINGERPRINT_MIGRATION) can carry this one.

Separately: the e2e-scoped red

That one is perry-codegen --test manifest_consistency: "Add the missing rows to crates/perry-api-manifest/src/entries.rs". Another lane already characterised it as base drift with api_manifest_source_identical: true and an api_docs_drift note ("generated docs add bun-pty from unchanged manifest"). Filing here only as a pointer — it wants its own issue if it is not already tracked.