Say why the doc-pages advisory fired, not only what to run (relay#56) #143

2026-09-07T19:40:55Z

paulhitt commented

2026-09-07 19:40:55 +00:00

(Migrated from gitlab.com)

Relates to #56.

The advisory printed the pinned SHA and HEAD and left it there. #56 records an hour spent blaming the runner for a red that a merge in another repository had caused — the message told you to regenerate and not why regenerating had suddenly become necessary.

It now lists the commits between the pin and HEAD that touched docs/, with author and subject, and says plainly that a failure below comes from a change in another repository rather than from anything in this one.

pinned:  9775fbf…
at HEAD: a1b2c3d…

flamenet-e2e has moved since this repo pinned it. Commits touching docs/:
  a1b2c3d Android is v3, and it has been run (relay#46)

If the check below fails, THAT is why — a change in another
repository, not anything in this one. See .e2e-ref.md …

Deliberately only in the -head advisory. The blocking doc-pages job runs against the pin, so when it fails somebody in this repo edited the markdown without regenerating — a local mistake, where the existing message is exactly right. Adding "another repo did this" there would be a lie most of the time.

Also drops --depth 1. git log PINNED..HEAD needs the history between the two, and a shallow clone has none of it — the old command would have printed nothing and looked like "no relevant commits". That is the same silent-nothing shape the issue is about, hiding inside the fix for it.

Validated through the ci/lint API rather than by pushing and watching, since a YAML mistake here produces a pipeline with zero jobs and a null error list.

Relates to #56. The advisory printed the pinned SHA and HEAD and left it there. #56 records **an hour spent blaming the runner** for a red that a merge in another repository had caused — the message told you to regenerate and not why regenerating had suddenly become necessary. It now lists the commits between the pin and HEAD that touched `docs/`, with author and subject, and says plainly that a failure below comes from a change in another repository rather than from anything in this one. ``` pinned: 9775fbf… at HEAD: a1b2c3d… flamenet-e2e has moved since this repo pinned it. Commits touching docs/: a1b2c3d Android is v3, and it has been run (relay#46) If the check below fails, THAT is why — a change in another repository, not anything in this one. See .e2e-ref.md … ``` **Deliberately only in the `-head` advisory.** The blocking `doc-pages` job runs against the **pin**, so when it fails somebody in this repo edited the markdown without regenerating — a local mistake, where the existing message is exactly right. Adding "another repo did this" there would be a lie most of the time. **Also drops `--depth 1`.** `git log PINNED..HEAD` needs the history between the two, and a shallow clone has none of it — the old command would have printed nothing and looked like "no relevant commits". That is the same silent-nothing shape the issue is about, hiding inside the fix for it. Validated through the `ci/lint` API rather than by pushing and watching, since a YAML mistake here produces a pipeline with zero jobs and a null error list.

paulhitt commented

2026-09-07 21:47:03 +00:00

(Migrated from gitlab.com)

mentioned in commit 335139ae20

mentioned in commit 335139ae20398ecbf8fa9ff6493adfa9621d80a9

paulhitt (Migrated from gitlab.com) merged commit 335139ae20 into main

2026-09-07 21:47:03 +00:00

paulhitt commented

2026-09-09 18:58:45 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#143