Skip to content

Re-read the two trigger-walk pastes that had stopped reproducing #227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
iderex merged 1 commit into from
Aug 30, 2026
Merged

Re-read the two trigger-walk pastes that had stopped reproducing #227

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 19 additions & 3 deletions docs/quality-parity.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -254,15 +254,25 @@ any of them goes into a required set. Issue #62 holds this walk.
### The command above reads a commit no pull request produced

`git rev-parse origin/main` resolves a commit on the default branch, which is
reached by a push. Three workflows in this tree carry no push trigger:
reached by a push. Four workflows in this tree carry no push trigger:

```
git grep -L 'push:' origin/main -- .github/workflows/
origin/main:.github/workflows/dco.yml
origin/main:.github/workflows/dependency-review.yml
origin/main:.github/workflows/pull-request.yml
origin/main:.github/workflows/smoke.yml
```

Three of those four run on a pull request and the fourth runs on neither kind of
commit, and only the first three are what this section is about.
`.github/workflows/smoke.yml` triggers on a published release, on a schedule and
on a manual dispatch, so it reports on no pull request and on no push, and it is
in this list for a reason the list is not about. That is the thing to read the
grep for: it gains a member every time this board adds a workflow that runs on
neither, and what would matter here is a file that does run on a pull request
appearing in it.

So the two kinds of commit report different sets, and the difference runs in
both directions. Between the head of the default branch and the head of a pull
request that landed on it, on 2026-08-16:
Expand Down Expand Up @@ -312,8 +322,8 @@ suite 86798670354, success
suite 86798547856, success
```

The cause is one trigger. Every push trigger in these files names the default
branch except one:
The cause is one trigger. Every push trigger in these files that names a branch
names the default branch except one, and one names no branch at all:

```
for f in $(git ls-tree --name-only origin/main .github/workflows/); do
Expand All @@ -327,11 +337,17 @@ done
.github/workflows/invariants.yml branches: [main]
.github/workflows/prose.yml branches: [main]
.github/workflows/records.yml branches: [main]
.github/workflows/release.yml tags:
.github/workflows/scorecard.yml branches: [main]
.github/workflows/unicode-guard.yml branches: ["**"]
.github/workflows/zizmor.yml branches: [ main ]
```

The `tags:` line is the second kind and it doubles nothing. A tag push is not a
branch push, so `.github/workflows/release.yml` starts on neither a pull request
nor the branch one is opened from, and the file says that at its own trigger.
What produces the repeated name is the entry above carrying every branch.

A branch pushed for a pull request therefore starts that one workflow twice,
and both runs report under its job name. The file gives the reason its trigger
is wide, and the reason is about which branches the guard covers rather than
Expand Down
Loading