Name the floor jobs after the packaging file, so a floor bump cannot delete a requirement

[iderex]

Part of #30, and it is the piece the answer of 31.08. on that issue named: give the floor job a stable name that carries no version, report the floor it built against in the step output instead, and the two floor contexts join the required set.

What was wrong with the name

A required context is a string the ruleset holds, and GitHub compares it to the name a check run reports with nothing reconciling the two. floor ${{ matrix.abi }} builds that string out of a matrix value, and raising a floor on this board is editing one number in one packaging file:

$ git grep -nE '^targetAbi:' -- build.yaml build-jf12.yaml
build-jf12.yaml:15:targetAbi: "12.0.0.0"
build.yaml:10:targetAbi: "10.11.0.0"

So with floor 10.11.0.0 required, the first floor bump removes a requirement instead of renaming one: every pull request hangs pending on a name nothing produces, there is no red check to point at, and the gate reads as satisfied while being absent. That is the failure docs/quality-parity.md already declines Scorecard analysis for, arriving from a third direction, and it is why these two were the last two of the fifteen left out of the set on 31.08. when the other four went in.

What the name is now

The packaging file, which is what identifies a line here - adding a line is adding a file, and raising a floor edits a number inside one. The two contexts become floor build.yaml and floor build-jf12.yaml.

Two names rather than one, and that is deliberate. The jobs are a matrix over the packaging files, so one shared name would report two check runs under one string, which is two things a ruleset cannot tell apart - the trap package.yaml names at its own package-lines job. The alternative shape is a single gate job that needs: the matrix and carries the only required name, which is what the sibling board's one ABI floor build context is. I did not take it, because it adds a job and a context to answer a naming problem, and because this change is meant to be the small one the answer described. Say so on the issue if the aggregated shape is wanted instead; it is a short follow-up rather than a rework.

What the name gave up is printed instead

A step of its own, so a reader of the run gets the number the name no longer carries:

$METADATA declares targetAbi $ABI on $FRAMEWORK. That is the floor this job builds against, and it is deliberately not in the check-run name.

It runs on every head, including a documentation head where the build itself does nothing.

The page

docs/quality-parity.md declares the two new names in the set to require, says why they changed, and records the neighbouring case: package 10.11.0.0, package 12.0.0.0 and package-lines carry a version for the same reason, are not in the set, and want the same repair the day they are.

The historical pastes on that page are untouched. Every one of them is a command's output at a named commit, 55f1ad2, 36eccab, 1a18979 and the rest, and those still reproduce there; editing them would be rewriting a measurement to match today.

What was run

$ npx --yes prettier@3.6.2 --check docs/quality-parity.md
Checking formatting...
All matched files use Prettier code style!

$ ./scripts/check-pasted-evidence.sh
read 118 pasted match lines in 24 document(s)
check-pasted-evidence: every pasted match line reproduces against the file it names.

$ ./scripts/check-negative-disclosures.sh
ran 4 negative disclosure(s) in 24 document(s)
check-negative-disclosures: every negative disclosure exits as the document says it does.

$ dotnet test Jellyfin.Plugin.Requests.Tests/Jellyfin.Plugin.Requests.Tests.csproj --configuration Release -f net10.0 --filter "FullyQualifiedName~RepositoryDocuments"

Bestanden!   : Fehler:     0, erfolgreich:    15, übersprungen:     0, gesamt:    15, Dauer: 48 ms - Jellyfin.Plugin.Requests.Tests.dll (net10.0)

Those fifteen are the legs that read these documents, including the one that refuses a workflow file with no row on the parity page. This change adds no workflow file.

The means

A change to a workflow file and a document, which is the means both halves already are. Nothing new is added to the tree: no language, no runtime, no dependency, and no script.

What this does not do, and it is the half that matters

It requires nothing. A ruleset is a repository setting rather than a file in this tree, so the two contexts are still declared and not live after this merges. What it removes is the reason they were held back. #30's second condition needs the edit that adds floor build.yaml and floor build-jf12.yaml to the required set on master, and that is yours.

The new names are read off this head rather than off the workflow file, which is the page's own rule for a name that goes into the set. Corrected after opening this pull request, where this paragraph said they had not been observed on a run:

$ gh api repos/Flowfin/jellyfin-plugin-requests/commits/0b46b54e9fe2eb8b405e3c993ec721653eed4203/check-runs         --jq '.check_runs[] | select(.name|startswith("floor")) | "\(.name)	\(.conclusion)"' | sort -u
floor build.yaml	success
floor build-jf12.yaml	success

So the two strings docs/quality-parity.md now declares are the two a check run reports here, and both are green.

Nobody else has read this. No second reader was available tonight.