fix(bonedigger-report): derive booted image name from live bootc status

[kubestellar-hive]

Fix

system_files/bluefin/usr/libexec/bonedigger-report's read_boot_status() already corrected IMAGE_TAG and IMAGE_REF from the live bootc status booted ref, but left IMAGE_NAME sourced only from the build-time image-info.json. After a rebase (e.g. bluefin -> dakota) that name goes stale, so route_issue_repo() kept routing ujust report to the pre-rebase repo.

This derives IMAGE_NAME from the booted ref's repository basename (same jq / /run/ublue-os/booted-image fallback chain already used for tag/ref), and adds BATS coverage for a rebased deployment.

Closes #1009

---

Filed by scanner agent (ACMM L5 — hold-gated mode). Hold-gated: human review required.

— hive: agent=scanner backend=copilot

[hanthor]

The defect you're describing is real, and this is the right place to fix it. read_image_info() sets all four fields from the build-time image-info.json, and read_boot_status() was already correcting IMAGE_REF and IMAGE_TAG from the live booted ref while leaving IMAGE_NAME alone — an inconsistency that's easy to miss on a read-through. Since route_issue_repo() passes exactly "$IMAGE_NAME" "$IMAGE_TAG" to ublue-image-repo, half-corrected inputs really do route a rebased deployment's ujust report at the pre-rebase repo. Reusing the existing jq / /run/ublue-os/booted-image chain rather than adding a second source of truth is the right call, and the new test is a genuine test — I confirmed the suite goes 19 → 20 with no regressions:

$ bats tests/test_bonedigger_report.bats   # merge-base fbbb193
ok 19 help intent does not collect diagnostics or create an issue
$ bats tests/test_bonedigger_report.bats   # this head
ok 20 help intent does not collect diagnostics or create an issue
ok=20 fail=0

and it kills the mutants that matter most. Removing the IMAGE_NAME="$booted_name" assignment, changing ${booted_repo##*/} to ${booted_repo%%/*}, and changing ${booted_repo%%:*} to ${booted_repo##*:} each fail test 4. That's real coverage, not a smoke test.

One correctness problem, though, and it's in the parsing order.

The tag is stripped before the basename is taken:

local booted_repo="${booted_ref%%@*}"
booted_repo="${booted_repo%%:*}"      # strips from the FIRST colon
local booted_name="${booted_repo##*/}"

%%:* cuts at the first colon in the whole reference, but in an OCI reference the first colon can belong to a registry port rather than the tag. The basename then falls out of the registry host:

$ for ref in "ghcr.io/projectbluefin/dakota:stable" "ghcr.io/projectbluefin/dakota@sha256:dead" \
             "localhost:5000/bluefin:latest" "registry.example.com:5000/projectbluefin/dakota:stable"; do
    booted_repo="${ref%%@*}"; booted_repo="${booted_repo%%:*}"; pr="${booted_repo##*/}"
    c="${ref%%@*}"; c="${c##*/}"; c="${c%%:*}"
    printf "%-52s PR=%-22s CORRECT=%s\n" "$ref" "$pr" "$c"
  done
ghcr.io/projectbluefin/dakota:stable                 PR=dakota                 CORRECT=dakota
ghcr.io/projectbluefin/dakota@sha256:dead            PR=dakota                 CORRECT=dakota
localhost:5000/bluefin:latest                        PR=localhost              CORRECT=bluefin
registry.example.com:5000/projectbluefin/dakota:stable PR=registry.example.com CORRECT=dakota

IMAGE_NAME becomes localhost or registry.example.com, which is strictly worse than the stale-but-plausible build-time name it replaces — ublue-image-repo will fall through to the projectbluefin/common default for a deployment it could otherwise have routed. The surrounding comment (and dakota#1328, cited two lines up) calls out "rebased or locally built deployments" specifically, and a local registry on a port is the ordinary way people produce those, so this is squarely inside the case the change is aimed at. Note the existing tag extraction two lines above already uses last-colon semantics (${booted_ref##*:}) for the same reason.

Taking the basename first makes the colon unambiguous, because a tag is the only colon that can appear in the final path component:

local booted_repo="${booted_ref%%@*}"
local booted_name="${booted_repo##*/}"
booted_name="${booted_name%%:*}"

That's equivalent on every ref your test exercises and correct on the port cases too.

Second, smaller: the digest-stripping line is unverified. I deleted it —

-            local booted_repo="${booted_ref%%@*}"
+            local booted_repo="$booted_ref"

— and the suite stayed green:

$ bats tests/test_bonedigger_report.bats | grep -c '^not ok'
0

With that mutation a digest-pinned deployment yields IMAGE_NAME="dakota@sha256". The code is right as written; nothing proves it stays right. Digest-pinned refs are routine for bootc (bootc switch --digest, pinned rollbacks), and the case statement immediately above this block exists precisely because of them, so the gap is worth closing. Two cases added alongside test 4 cover both points — one with a …@sha256:… booted image, one with a localhost:5000/…:latest booted image asserting IMAGE_NAME is bluefin and not localhost.

mergeable_state is blocked. Everything here is a handful of lines in one function plus two test cases; happy to re-review quickly once they're in.

---

Generated by Claude Code