The weekly freshness check could not fail, and the .nvmrc §4 asks for - #178
Merged
Conversation
Section 4 is one sentence: "`engines.node` is `>=22` and `.nvmrc` says `22`." The first half was here; the second was missing — in seven of the nine repositories, which is what happens to a rule with no gate behind it. Section 4 is the only section of CONVENTIONS.md that `conventions-gate.mjs` does not touch: it decides workflow file names (§2), AGENTS.md/CLAUDE.md pairing (§6) and .gitattributes (§6), and nothing at all about the toolchain. The file records what is already true rather than proposing a move: CI runs Node 22 here and `engines.node` already says `>=22`. What it changes is that `nvm use` picks that version instead of whatever the shell happened to have. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0146Q9UP9JavNhdDd8bqdQik
`run: node scripts/check-version.mjs | tee version.txt`
GitHub runs a `run:` step as `bash -e {0}` — errexit, but NOT pipefail. So the
pipeline reports its LAST command's status, and `tee` succeeds whenever it can
write the file. The step passed however stale the site was, and the
`if: failure()` step below it, the one that opens the stale-release issue, has
therefore never run.
That makes this a check that reports nothing and looks green doing it, which is
the failure mode this organisation names as the worst it can produce.
Measured rather than reasoned: a script exiting 1 through `| tee` under
`bash -e` gives the step exit 0; with PIPESTATUS it gives 1.
`abap2UI5/linter`'s upstream-sync.yml already solves the identical `node … |
tee` shape that way, so this copies a pattern rather than inventing one.
And while reading it: the closing line said "the documentation names the release
that exists - OK" even when the release API had been unreachable — two lines
under its own report that this was "UNVERIFIED". A green run then claimed more
than the run had established. It now says which of the two it checked. Still
exit 0 when the API is down: an outage is not a documentation defect.
Both branches exercised, the unreachable one with fetch stubbed out.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0146Q9UP9JavNhdDd8bqdQik
§6 wants a `CONTRIBUTING.md` in "every source and corpus repository", saying "how to propose a change, and what CI will check". This repository is a source repository — AGENTS.md, a test suite, seven gates — and had none. It and `playground` were the two without one. Follows the shape the other seven use: the shared two-line preamble pointing at the contribution guidelines on the site, then the commands that actually run here, and what `npm run check` covers. The part worth saying out loud is why a green VitePress build is not enough on its own: the gates hold these pages to what the OTHER repositories ship, so a page that quotes one is checked against it rather than against memory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0146Q9UP9JavNhdDd8bqdQik
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1.
release-freshness.ymlhas never been able to report anythingGitHub runs a
run:step asbash -e {0}— errexit, but not pipefail. Apipeline reports its last command's status, and
teesucceeds whenever it canwrite the file. So the step passed however stale the site was, and the
if: failure()step below it — the one that opens the stale-release issue —never ran.
A weekly check that reports nothing and looks green doing it is the failure mode
this organisation names as the worst it can produce.
Measured rather than reasoned:
abap2UI5/linter'supstream-sync.ymlalready handles the identicalnode … | teeshape withPIPESTATUS, so this copies an in-house patternrather than inventing one.
2. A green run claimed more than it had established
check-version.mjsended with `the documentation names the release that existsreport that this was UNVERIFIED. The three places had been compared against
each other and against nothing else.
It now says which of the two it actually checked. Still exit 0 when the API is
down: an outage is not a documentation defect, and the same reasoning
shared-file-gate.mjswrites down ("must not claim to have verified somethingthey did not") applies to the wording as much as to the verdict.
Both branches exercised — the unreachable one with
fetchstubbed out.3. The
.nvmrcCONVENTIONS §4 asks for§4 is one sentence: "
engines.nodeis>=22and.nvmrcsays22." The firsthalf was here; the second was missing — in seven of the nine repositories,
only
abap2UI5andlinterhad it. §4 is the one sectionconventions-gate.mjsdoes not touch at all, which is how it drifted. The filerecords what is already true: CI here already runs Node 22 and
engines.nodealready says
>=22. abap2UI5#2679 adds the gate that keeps it that way.Checks
npm run check— 33 tests, the VitePress build and all seven gates, green.