Call the shared pull request hygiene check beside this board's own gate

[iderex]

Scope: .github/workflows

What is wrong

iderex/wache now holds the half of the pull request hygiene rules that every
board in this fleet shares, and this board is not calling it. It carries its own
implementation instead, .github/pr-hygiene/hygiene.sh, and so does every other
board. That is the problem argued in iderex/operations#1556: on 22.08. nineteen
boards carried nineteen implementations of the same three or four rules, in four
languages, no two alike, so a two line change to a rule they share cost nineteen
edits and failed in nineteen different ways.

What the shared check refuses

Four things, and nothing else:

• a pull request body that is empty or is only whitespace
• a closing keyword (Closes, Fixes, Resolves) sitting inside a paragraph
  instead of on a line of its own
• a title that is a placeholder: wip, update, fix, changes, untitled
  and the rest of that list
• with the subject rule on, a non merge commit whose subject names no issue as
  [#N] or as owner/repo#N

It runs nine fixtures before it judges anything, one line that passes and one
line that bites per rule, and if a fixture fails the run refuses to judge at all
rather than showing a green tick with nothing behind it.

What does not change on this board

Nothing in .github/pr-hygiene/hygiene.sh and nothing in
.github/workflows/pr-hygiene.yml. The shared call runs beside them. Four of
this board's rules have no equivalent in the shared check at all:

• the scope comparison. Every issue a body names is read, its Scope: line at
  column zero is taken as a set of path prefixes, and the changed paths are
  compared against the union of them by whole path segment, so
  docs/decisions admits docs/decisions/0001.md and refuses
  docs/decisions-old/0001.md. The shared check reads no paths.
• the qualifier aware reading of a reference. A number written as
  owner/repo#123 names an issue on that board and is not read as one here, so
  a body can paste evidence quoting another repository without turning it into a
  question about this one.
• naming an issue without closing it, which is this board's practice. The rule
  here is that the body names an issue, not that it closes one, because the
  definition of done is frequently not met by the change that names it.
• the emptiness rule as this board means it. Here a body is empty when it says
  nothing the template did not: headings, HTML comments and bare issue
  references are stripped before the question is asked, so the skeleton with the
  number filled in is refused. The shared check refuses only a body that is
  literally blank.

A local rule goes only once the shared check is shown to cover it, one rule at a
time, in its own change. Standardising by deleting coverage would be worse than
the duplication.

Why the subject rule is switched off

Because this board puts the reference in the body on purpose, and its own check
reads the body. Measured rather than assumed:

$ gh api "repos/Flowfin/core/commits?per_page=100" \
    --jq '.[] | select(.parents|length==1) | .commit.message | split("\n")[0]'
authored subjects:        52
carrying [#N]:             0
carrying (#N) or any #N:  38
of the last twenty:        8

Not one subject in this repository is in the square brackets the fleet rule
wants, and the twelve most recent carry no reference in the subject at all.
Calling the check with the subject rule on would red every pull request here on
day one. Calling it with that one rule off says this board does not meet the
rule yet, which is a statement somebody can act on. Not calling the check at all
would say nothing.

What done means

One file exists, .github/workflows/shared-hygiene.yml, it calls
iderex/wache/.github/workflows/pr-hygiene.yml pinned by commit hash, and the
Shared hygiene check appears on a pull request here and finishes green with
the nine fixture lines and the line saying the subject rule is off visible in
its log. Every other check on this board stays the colour it already is, and
.github/pr-hygiene/hygiene.sh is byte for byte unchanged.

If the shared call cannot run green beside the local gate, this issue closes
unmerged and says what refused it.

The reference stays pinned by commit hash with the version in the comment
beside it. A moving @main would let the called repository change what executes
on this board without anybody reviewing the change, and zizmor here refuses an
unpinned reference anyway.

What this waits on

Nothing. The shared check exists, it is tagged, and it has been called across a
repository boundary from two other boards already.

[iderex]

Not done, and the reason is not on this board.

#179 adds the file and the shared check runs green on it, but it
buys that tick by cancelling this board's own gate. The called workflow claims
pr-hygiene-<pull request number> as its concurrency group and
.github/workflows/pr-hygiene.yml here claims the same string, so the run
created second cancels the other and the local gate is the one that dies:
cancelled one second after creation, no steps, no verdict.

Three placements of a group on the caller were tried, and the local gate was
cancelled in all three: no group at all (run 32611192849), a group of the
caller's own at workflow level (run 32611334638), and the same group on the
calling job (run 32611542281). The second one settles it. Had the caller's block
decided the run's group, nothing would have been left in pr-hygiene-<number>
to cancel the local gate, and it was cancelled anyway. The called workflow
claims that group independently of its caller.

So the fix is not available from this board without editing the gate here to
work around a name chosen on another one, and that is the wrong direction. It is
filed where it belongs, as iderex/wache#4: the group has to be namespaced with
the calling repository and workflow, followed by a version bump and a pin move
on the boards that already call v1.0.0.

Until that lands this issue stays open and #179 stays open and red.
The evaluation does not change: the pull request goes green, with both the
Shared hygiene tick and this board's own verdict on it, and no edit to
.github/pr-hygiene/hygiene.sh.

One thing this turned up on the way. iderex/bremsweg#143 carries the same group
name, the same cancellation happened there, and that pull request was merged
with the cancelled check still red on it. It is worth looking at again.

[iderex]

The pin cannot be rolled forward past this, and there is now a tag that reads as
though it could be. iderex/wache carries v1.1.0, and the file this board
would call at that tag is byte for byte the file at the v1.0.0 commit
#179 is already pinned to:

gh api repos/iderex/wache/git/ref/tags/v1.1.0 --jq .object.sha
cd18e26718d6ca88a462396a7a21f629542ff94c

gh api repos/iderex/wache/git/tags/cd18e26718d6ca88a462396a7a21f629542ff94c --jq .object.sha
73e49a089ff01bec26f3425cfae0ea8409c880cc

for r in 9b311243c2d0d0ced7feb957a20bc178acce6a5d 73e49a089ff01bec26f3425cfae0ea8409c880cc; do
  gh api "repos/iderex/wache/contents/.github/workflows/pr-hygiene.yml?ref=$r" --jq .content > "$r.b64"
  base64 -d "$r.b64" > "$r.yml"
done
wc -c 9b311243*.yml 73e49a08*.yml
 6412 9b311243c2d0d0ced7feb957a20bc178acce6a5d.yml
 6412 73e49a089ff01bec26f3425cfae0ea8409c880cc.yml
12824 total

diff 9b311243*.yml 73e49a08*.yml ; echo "exit=$?"
exit=0

The group also reads unchanged on that repository's default branch, which is
where anybody checking whether the fix has landed will look:

gh api repos/iderex/wache/contents/.github/workflows/pr-hygiene.yml --jq .content | base64 -d | grep -A2 '^concurrency:'
concurrency:
  group: pr-hygiene-${{ github.event.pull_request.number }}
  cancel-in-progress: true

gh issue view 4 --repo iderex/wache --json state --jq .state
OPEN

So moving the pin in #179 to v1.1.0 changes nothing here and the
cancellation happens exactly as it does at the current pin. The argument for why
the repair belongs on the other board is already above and I am not making it a
second time.

No condition and no scope on this issue has changed.