Report a workflow that concluded non-success on the default branch

[iderex]

The target gate carries a check reported as Report any workflow that concluded non-success on the default branch. It exists because a scheduled or
post-merge workflow that starts failing has nothing in front of it. Nobody is
waiting on its result, so it can stay red for weeks, and the checks that only run
after a merge are exactly the ones nobody watches.

This board will have several of those by the end of this milestone: the scheduled
mutation run, the coverage-guided fuzzing, the supply-chain self-audit and the
speed measurement.

What this produces

A run that reads the recent conclusions of every workflow on the default branch
and reports any that ended in something other than success.

An issue opened rather than a notification sent, so the report survives being
missed.

A stated list of the workflows it examined, so that a workflow it has never heard
of cannot be read as one it checked and found healthy.

Done when

The report runs on a schedule, a deliberately failed scheduled workflow produces
an issue, and the run prints the full list of workflows it examined. Blocked on
#85 and #66.

[iderex]

I ran the report this issue asks for, once and by hand, against the default branch, so that what gets built later has a baseline to compare against rather than starting from nothing.

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" --jq '.total_count'
97

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[] | select(.conclusion != "success")
        | "\(.name)\t\(.event)\t\(.conclusion)\t\(.created_at)\t\(.head_sha[0:7])"'
unicode-guard	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Workflow Security Analysis	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Scorecard supply-chain security	push	cancelled	2026-08-08T22:29:42Z	4bcdf97

Ninety seven runs have ever concluded on the default branch and three of them are not success. All three are cancellations on one head, and all three have a successful counterpart on the head that replaced it four seconds later, because two merges landed in the same moment and the second cancelled the first:

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[] | select(.created_at >= "2026-08-08T22:00:00Z" and .created_at <= "2026-08-08T23:00:00Z")
        | "\(.name)\t\(.conclusion)\t\(.created_at)\t\(.head_sha[0:7])"' | sort -k3
Workflow Security Analysis	cancelled	2026-08-08T22:29:42Z	4bcdf97
Workflow Security Analysis	success	2026-08-08T22:29:46Z	4a24f93
Scorecard supply-chain security	cancelled	2026-08-08T22:29:42Z	4bcdf97
Scorecard supply-chain security	success	2026-08-08T22:29:45Z	4a24f93
unicode-guard	cancelled	2026-08-08T22:29:42Z	4bcdf97
unicode-guard	success	2026-08-08T22:29:45Z	4a24f93

So nothing is standing red on the default branch today, and a report written now would have to decide whether a superseded cancellation is worth an issue. My reading is that it is not, and that the report should say it excluded them rather than filter them silently, because a cancellation that was not a supersession is a real answer.

One of the four things the body expects this milestone to produce is already here. The supply chain self audit is in the tree and it runs on a weekly trigger and on every push to the default branch:

awk '/^on:/{p=1} p&&/^permissions:/{exit} p{print}' .github/workflows/scorecard.yml
on:
  # Branch-Protection check only reads the default branch's ruleset.
  branch_protection_rule:
  # Keeps the Maintained check current and re-scores against upstream drift.
  schedule:
    - cron: "27 4 * * 1"
  push:
    branches: [main]

The shape this issue exists against is therefore not something the board will have later. It has one instance now, and two more workflows that conclude on the default branch beside it.

The third condition has a trap in it that is cheaper to see before the report is written than after. Seven workflows are registered and only three have ever concluded on the default branch:

gh api repos/Flowfin/core/actions/workflows --jq '.workflows[] | "\(.name)\t\(.path)\t\(.state)"'
DCO	.github/workflows/dco.yml	active
Dependency review	.github/workflows/dependency-review.yml	active
doc-paths	.github/workflows/doc-paths.yml	active
pr-hygiene	.github/workflows/pr-hygiene.yml	active
Scorecard supply-chain security	.github/workflows/scorecard.yml	active
unicode-guard	.github/workflows/unicode-guard.yml	active
Workflow Security Analysis	.github/workflows/zizmor.yml	active

The other four declare pull_request and nothing else, so they produce no conclusion on the default branch at all and a report reading default branch conclusions has nothing to read for them. A list naming seven, with no line saying which three it can actually see, is read as seven examined and found healthy, which is the reading the third condition is written against.

The refusal direction is not shown here. Proving that a workflow which concluded non-success produces an issue would mean putting a workflow on the default branch that fails on purpose, and I have not done that.

[iderex]

The baseline above no longer reproduces from the command that produced it, and
the reason bears on the report rather than on the health of the branch.

There are 116 concluded runs on the default branch today, and one request hands
over at most a hundred of them:

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" --jq '.total_count'
116

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" --jq '.workflow_runs | length'
100

So one request answers 116 in one field and returns 100 rows in the other. The
sixteen it leaves out are the oldest, and all three non-success runs are among
them. The command recorded above now prints nothing:

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[] | select(.conclusion != "success")
        | "\(.name)\t\(.event)\t\(.conclusion)\t\(.created_at)\t\(.head_sha[0:7])"'

and the same read across every page still finds them:

gh api --paginate "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[] | select(.conclusion != "success")
        | "\(.name)\t\(.event)\t\(.conclusion)\t\(.created_at)\t\(.head_sha[0:7])"'
unicode-guard	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Workflow Security Analysis	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Scorecard supply-chain security	push	cancelled	2026-08-08T22:29:42Z	4bcdf97

The oldest run the first page carries concluded after all three of them:

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[-1] | "\(.name)\t\(.created_at)\t\(.head_sha[0:7])"'
Scorecard supply-chain security	2026-08-09T05:50:02Z	10098fa

Raising the page size does not move the boundary, because a hundred is the
ceiling and the request is answered at it without saying so:

gh api "repos/Flowfin/core/actions/runs?branch=main&per_page=200" \
  --jq '{total: .total_count, returned: (.workflow_runs|length)}'
{"returned":100,"total":116}

The three runs are the same three, they are still superseded cancellations on one
head, and nothing is standing red on the default branch. What has changed is that
the unpaginated read answers with an empty set, and an empty set from this
question is read as nothing concluded non-success rather than as nothing
concluded non-success inside a window the output does not name. The reading gets
quieter as the branch collects runs, which is the opposite of what a report on
unwatched conclusions is for.

Two things follow for what gets built here. The read either pages or states the
window it covered, and stating the window is the same shape the third condition
already asks for over the workflow list, so one sentence in the output can carry
both. And a baseline taken from a single page expires without any sign that it
did, which is why I am recording the boundary rather than a fresh count of
non-success runs.

The workflow registry is unchanged at seven:

gh api repos/Flowfin/core/actions/workflows --jq '.total_count'
7

I have changed no condition and no scope.

[iderex]

The two counts recorded on this issue have both moved, and the one that matters
is the set a report reading default-branch conclusions can actually see. Read at
c8367798eb3c245ace4d47caa06ff2bda6e6b294.

The registry is eight rather than seven:

gh api repos/Flowfin/core/actions/workflows --jq '.total_count'
8

gh api repos/Flowfin/core/actions/workflows --jq '.workflows[] | "\(.name)\t\(.path)\t\(.state)"'
DCO	.github/workflows/dco.yml	active
Dependency review	.github/workflows/dependency-review.yml	active
doc-paths	.github/workflows/doc-paths.yml	active
pr-hygiene	.github/workflows/pr-hygiene.yml	active
Scorecard supply-chain security	.github/workflows/scorecard.yml	active
shell-analysis	.github/workflows/shell-analysis.yml	active
unicode-guard	.github/workflows/unicode-guard.yml	active
Workflow Security Analysis	.github/workflows/zizmor.yml	active

The entry that is new declares a push to the default branch beside its pull
request trigger, which is what the four additions before it did not:

git show origin/main:.github/workflows/shell-analysis.yml \
  | awk '/^on:/{p=1} p&&/^permissions:/{exit} p{print}'
on:
  pull_request:
    types: [opened, synchronize, reopened]
  push:
    branches: [main]

So the visible set is four rather than three, and the count comes from what has
concluded rather than from what a trigger promises:

gh api --paginate "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[].name' | sort | uniq -c | sort -rn
     52 Scorecard supply-chain security
     50 Workflow Security Analysis
     50 unicode-guard
      5 shell-analysis

The four the registry carries and that list does not are the same four as
before, each declaring pull_request and nothing else:

comm -23 <(gh api repos/Flowfin/core/actions/workflows --jq '.workflows[].name' | sort) \
         <(gh api --paginate "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
             --jq '.workflow_runs[].name' | sort -u)
DCO
Dependency review
doc-paths
pr-hygiene

What this costs the third condition is that both halves of the sentence it asks
for move on their own. A list of eight with no line saying which four it can see
is read as eight examined and found healthy, and a report or a baseline written
to seven and three is wrong in both numbers today without anything on this issue
having changed. The mechanism is a workflow acquiring a default-branch trigger,
which happens in the same change that adds the workflow and is invisible to
anybody reading the registry alone, so the line naming the window has to be
derived on every run rather than written once.

Nothing is standing red on the default branch. The only conclusions that are not
success are the three superseded cancellations already read on this issue, and
they are still the same three:

gh api --paginate "repos/Flowfin/core/actions/runs?branch=main&per_page=100" \
  --jq '.workflow_runs[] | select(.conclusion != "success")
        | "\(.name)\t\(.event)\t\(.conclusion)\t\(.created_at)\t\(.head_sha[0:7])"'
unicode-guard	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Workflow Security Analysis	push	cancelled	2026-08-08T22:29:42Z	4bcdf97
Scorecard supply-chain security	push	cancelled	2026-08-08T22:29:42Z	4bcdf97

The refusal direction is still not shown. Proving that a workflow which concluded
non-success produces an issue would mean putting a workflow on the default branch
that fails on purpose, and I have not done that.

What this issue waits on is unchanged. #85 and #66 are both open:

for n in 85 66; do gh issue view $n --repo Flowfin/core --json number,state --jq '"\(.number) \(.state)"'; done
85 OPEN
66 OPEN

I have changed no condition and no scope.