The workflow audit is red on every pull request opened against this board, and
nothing in the tree or in flight repairs it.
What it says:
$ gh run view 31968878147 --log-failed
warning[ref-version-mismatch]: action's hash pin has mismatched or missing version comment
--> ./.github/workflows/codeql.yml:71:84
|
71 | uses: github/codeql-action/init@5595ccaf912efad79be6eef63a5619ff05969be3 # v4
| ^^ points to commit ff2f1c621b7f
| is pointed to by tag v4.37.6
4 findings (2 suppressed, 2 unsafe fixes): 0 informational, 0 low, 2 medium, 0 high
Two sites, and they are the two pinned with a major-version comment rather than
an exact one:
$ grep -rn codeql-action .github/workflows/
.github/workflows/codeql.yml:71: uses: github/codeql-action/init@5595ccaf912efad79be6eef63a5619ff05969be3 # v4
.github/workflows/codeql.yml:89: uses: github/codeql-action/analyze@5595ccaf912efad79be6eef63a5619ff05969be3 # v4
.github/workflows/scorecard.yml:93: uses: github/codeql-action/upload-sarif@d1ba80a13dd99fba24a470575428917156a28b43 # v4.37.5
.github/workflows/zizmor.yml:78: uses: github/codeql-action/upload-sarif@d1ba80a13dd99fba24a470575428917156a28b43 # v4.37.5
The hash did not change and the comment did not change. The tag the comment
names moved:
$ gh api repos/github/codeql-action/git/ref/tags/v4 --jq '.object.sha'
988661ebb5e81487b3fb31b2185d2856c0a10679
$ gh api repos/github/codeql-action/releases/tags/v4.37.6 --jq '.published_at'
2026-08-04T13:34:40Z
So a comment reading # v4 is a claim about a moving reference, and it stops
being true the moment upstream tags a release without anybody here touching a
file. The audit is right to say so. What it means in practice is that this board
went red without a change, and stays red until somebody moves the comment or the
pin.
The update configuration does not reach these two. It has an open pull request
for the sites pinned with an exact version and none for the sites pinned with a
major one, which is the shape of the tool rather than a gap in the
configuration.
Nothing here has decided which of the two spellings this repository wants. The
exact-version comment is what the update tool acts on and what the audit can
check; the major-version comment is what most published examples use and what
these two sites carry. Picking one is a decision about how this board wants its
pins read, not a repair of a broken line, which is why this issue states the
state and does not take it.
The three ways out, and each costs something different. Moving the two comments
to the exact version the hash points at makes them checkable and brings both
sites under the update tool. Moving the pins to where v4 points now repairs
the mismatch and takes a version that has not walked this board's gate. Silencing
the audit at those two sites keeps the board green and removes the thing that
noticed, which is the option worth writing down so it can be refused rather than
arrived at.
The audit is not in the required set today, so this does not refuse a merge:
$ gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request
That is what makes it worth an issue rather than a red gate somebody has to
clear. A check that is red on everything and blocks nothing is a check people
learn to scroll past, and the next finding it reports arrives in a column
everybody has stopped reading. Issue #26 is where the required set is decided
and it does not settle this, because the audit being required would turn a
board-wide red into a board-wide block rather than into a repair.
Done when the two sites in .github/workflows/codeql.yml carry a comment the
audit does not report a mismatch for, the spelling this repository uses for a
pin comment is written where a reader of those files will see it, and
gh run list --workflow=zizmor.yml --branch main --limit 1 --json conclusion --jq '.[].conclusion'
prints success on the default branch after the change.
The workflow audit is red on every pull request opened against this board, and
nothing in the tree or in flight repairs it.
What it says:
Two sites, and they are the two pinned with a major-version comment rather than
an exact one:
The hash did not change and the comment did not change. The tag the comment
names moved:
So a comment reading
# v4is a claim about a moving reference, and it stopsbeing true the moment upstream tags a release without anybody here touching a
file. The audit is right to say so. What it means in practice is that this board
went red without a change, and stays red until somebody moves the comment or the
pin.
The update configuration does not reach these two. It has an open pull request
for the sites pinned with an exact version and none for the sites pinned with a
major one, which is the shape of the tool rather than a gap in the
configuration.
Nothing here has decided which of the two spellings this repository wants. The
exact-version comment is what the update tool acts on and what the audit can
check; the major-version comment is what most published examples use and what
these two sites carry. Picking one is a decision about how this board wants its
pins read, not a repair of a broken line, which is why this issue states the
state and does not take it.
The three ways out, and each costs something different. Moving the two comments
to the exact version the hash points at makes them checkable and brings both
sites under the update tool. Moving the pins to where
v4points now repairsthe mismatch and takes a version that has not walked this board's gate. Silencing
the audit at those two sites keeps the board green and removes the thing that
noticed, which is the option worth writing down so it can be refused rather than
arrived at.
The audit is not in the required set today, so this does not refuse a merge:
That is what makes it worth an issue rather than a red gate somebody has to
clear. A check that is red on everything and blocks nothing is a check people
learn to scroll past, and the next finding it reports arrives in a column
everybody has stopped reading. Issue #26 is where the required set is decided
and it does not settle this, because the audit being required would turn a
board-wide red into a board-wide block rather than into a repair.
Done when the two sites in
.github/workflows/codeql.ymlcarry a comment theaudit does not report a mismatch for, the spelling this repository uses for a
pin comment is written where a reader of those files will see it, and
prints
successon the default branch after the change.