ci(chipdb): cache two more workflows, state why five probes stay uncached

[gHashTag]

Stacked on #852 (base fix/ci-chipdb-cache). Merge #852 first; this PR's diff is the 7 workflows only.

What

#852 moved 54 of 61 chipdb-building workflows onto the composite action .github/actions/openxc7-chipdb. This PR settles the other 7 (#846).

Cached through the action:

workflow	trigger	why it pays
part-coverage.yml	daily cron, 4-part matrix	ran bbaexport for every part, every day
fpga-hslm-bitstream.yml	push/dispatch	keyed on the ID of regymm/openxc7:latest, so it misses exactly when the tag moves

In part-coverage.yml the chipdb step has continue-on-error: true. A chipdb failure is still an INCONCLUSIVE verdict, as it was when the chipdb was built inside the build step, and it does not stop the job before the verdict is written.

Left uncached on purpose. Each has a # chipdb-uncached: <reason> line directly above the step that builds its chipdb:

workflow	reason
openxc7-vs-vivado-openxc7-half.yml	chipdb built from the nextpnr-xilinx tree at NEXTPNR_REV, not the image
bufr-divide-probe.yml	bbaexport runs after checking out NEXTPNR_STOCK
iddr-vivado-diff.yml	nextpnr and the chipdb are built here from NEXTPNR_REV and PRJXRAY_DB_REV
iddr-golden-diff.yml	the action would fit, but the probe has run 3 times, last 2026-08-18, and it is the instrument behind openXC7/nextpnr-xilinx#114
router-vcc-reducer.yml	same: 3 runs, last 2026-08-18, the reducer promised on openXC7/nextpnr-xilinx#114

For the first three, an image-keyed cache would hand them a chipdb built from a different nextpnr revision, with possibly different constids. That is a wrong result, not a slow one.

Measured

• part-coverage run 37196269484, "Build it, all the way to frames" (chipdb included): 87 s (xc7a35t), 437 s (xc7k325t), 87 s (xc7s50), 351 s (xc7a200t).
• Chipdb coverage from the loop's classifier (speed coverage):

tree	chipdb cached	cached, or uncached with a stated reason
main 57de4a1	1/61	1/61
#852 head 30b2919	54/61	54/61
this PR	56/61	61/61

• The classifier gives the marker its own class, REASONED, separate from cached. The reason must be at least 20 characters and must be a comment line. It excuses a missing cache only, never a run_id key or a floating-tag key. Self-test 55/55, and 4 of 4 mutants of the rule are killed.
• Local checks: all 7 files parse, every step has exactly one of uses/run, and the local action exists and comes after actions/checkout. actionlint was not run, and the repo has no actionlint workflow. The Run syntax gate parses every run: script on this PR.

Why it is safe

• Each probe change is one comment line. Their behaviour is byte-for-byte unchanged.
• part-coverage keeps its verdict logic. chipdb_rc now comes from the action step's outcome instead of the docker run exit code.
• fpga-hslm-bitstream already pulled :latest. The action reuses the image already on the runner, so the chipdb and the nextpnr step share one image.

Not measured

• bbasm in the pinned image. part-coverage pins regymm/openxc7@sha256:eced1cdd…. That image installs bbasm with cp bbasm /usr/local/bin/ || true, so "bbasm is on PATH" there is an assumption. The action has only been proven on :latest. Two dispatches of part-coverage on this branch (a miss, then a hit) settle it and give the hit-versus-miss step times. Results go on ci: 7 workflows build a chipdb with no cache #846.
• Cache size. The size per part, against the 10 GB repository cache limit (ci: setup-zig caches fill the 10 GB Actions cache and evict every chipdb #844), comes from the same dispatches.
• fpga-hslm-bitstream has not been run on this branch.

Refs #846 #851

🤖 Generated with Claude Code

[gHashTag]

The hit run: chipdb drops from 797 s to about 10 s across the four parts

Both runs dispatched part coverage on this branch at the same commit, a4421f1, with the same image (regymm/openxc7@sha256:eced1cdd). The first had an empty cache, and the second started 36 minutes after the first one finished.

• miss: 37226894783
• hit: 37230734307

part	chipdb step, miss	chipdb step, hit	chipdb bytes (both runs)	cache entry, compressed	job, miss	job, hit
xc7a35tcsg324-1	69 s	1 s	92,709,864	19.4 MB	189 s	123 s
xc7s50csga324-1	85 s	1 s	92,150,508	19.3 MB	180 s	100 s
xc7a200tfbg484-2	296 s	4 s	332,105,196	71.4 MB	397 s	111 s
xc7k325tffg676-1	347 s	4 s	460,628,100	99.2 MB	467 s	118 s
total	797 s	10 s		209 MB	1233 s	452 s

Step times come from the API's whole-second timestamps, so the hit column is ±1 s.

What the logs show:

• In the hit run, all four jobs log Cache hit for: chipdb-<part>-7b00f1d6…-bbasm-le-v1 and cache-hit=true, and the save step is skipped.
• In the miss run, all four log Cache not found, build the chipdb inside the eced1cdd image, and then log Cache saved. So the bbasm path works in that image, which answers the question left open when this PR was opened.
• The restored file has the same byte count as the built one for every part. Every job in both runs passes its verdict.

After the cache, image pull is most of the job. In the hit run, pull takes 68–96 s of the 100–123 s per job.

Not measured

• Whether the bitstreams are byte-identical between the hit and the miss run. The workflow prints no output hash. Only "same chipdb size, same verdict" is shown.
• The first run on main. GitHub scopes a cache saved on a branch to that branch. These four entries are on refs/heads/ci/chipdb-no-cache, so main will miss once after merge and then save its own entries.
• Cache pressure. This repository holds 101 cache entries, 6.79 GB of the 10 GB limit. The four entries above add 209 MB, and every new image digest adds another set. Eviction order was not observed.

Refs #846, #851

🤖 Generated with Claude Code

[tri-claw]

Summary by t27-bees

This PR moves two workflows (part-coverage.yml, fpga-hslm-bitstream.yml) onto the shared composite action for chipdb caching, and documents why five probe workflows remain uncached with explicit # chipdb-uncached: comments. The changes are minimal and focused: the cached workflows swap inline docker run for the action, while the uncached ones only gain a comment line explaining the revision-mismatch or low-run-count rationale.

Worth a look

• .github/workflows/part-coverage.yml:198-225 – New Chipdb (cached per part and image) step uses continue-on-error: true and the build step derives chipdb_rc from steps.chipdb.outcome. If the composite action ever returns a non-success outcome that isn't a real failure (e.g., a transient cache error), the verdict logic could misclassify a run. The current mapping (success → 0, else → 1) assumes only success means a valid chipdb.
• .github/workflows/part-coverage.yml:215 – The build step references steps.chipdb.outputs.cache-hit and steps.chipdb.outputs.key. If the composite action changes its output names, this logging line will print empty values but won't break the build.
• .github/workflows/fpga-hslm-bitstream.yml:76-83 – The action is invoked with image: regymm/openxc7:latest. The cache key is derived from the image digest at pull time; if the :latest tag moves between the docker pull in the previous step and the action's internal pull, the action could pull a different digest than the one used for the cache key, causing a spurious miss. The preceding step does docker pull "$OPENXC7_IMAGE" with retries, so the image is already local, but the action may still re-pull.
• .github/workflows/bufr-divide-probe.yml:87 – Comment states bbaexport runs from the image's tree after checking out NEXTPNR_STOCK. The workflow does check out NEXTPNR_STOCK earlier, but the chipdb step runs bbaexport inside the Docker image (regymm/openxc7), not from the checked-out tree. The comment may be slightly inaccurate about where bbaexport runs, though the caching decision (uncached) remains correct because the revision differs.
• .github/workflows/iddr-vivado-diff.yml:264 – Comment says nextpnr and the chipdb are both built here from NEXTPNR_REV and PRJXRAY_DB_REV. The chipdb step shown (Build the same design with openXC7) runs continue-on-error: true and appears to invoke nextpnr directly; verify that it actually builds the chipdb from those revisions rather than using the image's chipdb, otherwise the uncached reason would be invalid.

---

_{Read: 7 files, +38 -19, the whole diff. Head df19c26. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.}