v0.3.1 fixed the action, but the v1 tag every consumer is told to use still points at v0.3.0

[SebHenn]

Version: cifail 0.3.1 (CLI, from nuget.org); action resolved as SebHenn/ci-failure-intelligence@v1

Summary

v0.3.1 fixed the two bugs in #19 — the swallowed --report pair and the composite step dying under
an inherited errexit. The release notes are accurate and the fix is real. But the moving major
tag was not moved with it, so no consumer following the README gets it.

$ git rev-parse --short v1
775e98c   chore: release v0.3.0

$ git rev-parse --short v0.3.1
a571773   chore: release v0.3.1

$ git merge-base --is-ancestor 2a25628 v1 ; echo $?
1         # "Honour every --report pair" is NOT an ancestor of v1

The difference is visible in the shipped script:

$ git show v1:action.yml     | grep -n 'set +e'      # nothing
$ git show v0.3.1:action.yml | grep -n 'set +e'
96:        set +e

README.md recommends uses: SebHenn/ci-failure-intelligence@v1 in five places (lines 334,
366, 378, 391, 407). Every one of them resolves today to the build with the bug the release fixed.

Why this is worth its own task rather than a footnote on #19

The failure mode is identical to the one #19 was about, and just as silent. A consumer reads a
changelog entry saying the action no longer dies without explaining itself, changes nothing —
because @v1 is what the README already told them to write — and keeps getting a red step with no
output. There is nothing in the repository that would tell them why, and the natural conclusion is
that the fix does not work, not that they are running last month's build. @v1 is the only
documented pin, so this is not an unusual configuration; it is the recommended one.

Expected

Publishing vX.Y.Z moves vX to the same commit, so the documented pin means "the newest release
in this major line". Ideally in the release workflow rather than by hand — a tag that has to be
remembered gets forgotten exactly like this one.

git tag -f v1 v0.3.1 && git push --force origin v1

Worth considering alongside it: the action does not report its own version anywhere in its output,
so "which build of the action ran?" is unanswerable from the log. One line naming the resolved
version in the step summary would have made this five seconds to diagnose instead of a comparison
of two trees.

In the meantime

cartographer has repinned to @v0.3.1 and will move back to @v1 once it tracks releases. This is
the smallest reversible unblock, and it is marked in that repository's workflow as
# TT-<this task> so it is greppable.

[SebHenn]

Thanks — the second half of this is a real gap and #22 fixes it. The first half needs a
correction, though: v1 was moved on release day. Against the remote:

$ git ls-remote origin refs/tags/v1
a5717737c92fcf33bf2123ed8cc401a9c3532c27   refs/tags/v1
$ git rev-parse v0.3.1
a5717737c92fcf33bf2123ed8cc401a9c3532c27
$ gh api repos/SebHenn/ci-failure-intelligence/contents/action.yml?ref=v1 \
    --jq .content | base64 -d | grep -n 'set +e'
96:        set +e

release.yml's finalize job pushed it at 2026-08-21T18:58:48Z — about 18 hours before this
was filed — and it has always done that; it is not a step that was added in response.

What git rev-parse --short v1 reported was a stale local tag. git fetch will not move a
tag that already exists locally; it needs --force. Any clone that had seen v1 before v0.3.1
kept reporting 775e98c indefinitely, and git fetch --tags says so only if you read its
stderr:

$ git fetch --tags
 ! [rejected] v1 -> v1  (would clobber existing tag)
$ git fetch --tags --force
$ git rev-parse --short v1
a571773

This repo's own working clone was in exactly that state, which is how the report reproduced so
cleanly. So @v1 has been serving the fix all along — worth re-checking whether cartographer's
red step was actually the old build.

That said, the diagnosis took a comparison of two trees, and it should not have: the action
reported nothing about itself. That is the part being fixed. Every step now opens with

cifail action v0.3.1 (SebHenn/ci-failure-intelligence@v1) | cifail 0.3.1 | image ghcr.io/sebhenn/cifail:latest@sha256:…

in the log, at the foot of the step summary, and in the PR comment — plus action-version and
image-digest outputs. It names all three separately-moving things, including the image digest,
since :latest moves as well and runners cache. The version is stamped in action.yml and
scripts/check-versions.sh fails the build if it drifts.

Your "ideally in the release workflow rather than by hand" point still landed, from the other
direction: the v1 move was fire-and-forget, so a failed push would have gone green and
produced precisely the symptom described here. It is now verified with git ls-remote after the
push, and skipped when the tag being released is not the newest version tag, so re-releasing an
older patch line cannot drag v1 backwards.

Leaving this open until #22 merges and ships. @v0.3.1 is a fine place to sit in the meantime —
the provenance line will make moving back to @v1 verifiable rather than hopeful.