ci: validate generated markup against Gutenberg's own block validator #137

Merged

peterswimm merged 6 commits from ci/gutenberg-block-validation into main 2026-09-14 19:02:21 +00:00

Conversation 0 Commits 6 Files changed 6 +4887

peterswimm commented 2026-09-14 18:51:08 +00:00

Owner

Copy link

#136 fixed five pages whose wrappers WordPress would not accept. This is the gate that would have caught them.

WordPress rebuilds a block's markup from its attributes and compares the two. When they disagree the editor offers "Attempt Block Recovery", and recovering in the Site Editor saves a copy into the database that then shadows the theme's own file — which is how /news/ ended up rendering from an override. A mismatch forks the page; it does not stay an editor warning.

Nothing here could have caught it. copy_coverage counts text, forgeblock_validate checks the ForgeBlock contract, and neither knows what WordPress does with a block's attributes. This asks WordPress's own packages.

Scope

• .forgejo/block-validation/validate-blocks.cjs — parses markup with @wordpress/blocks, registers the core blocks, and registers every toilville/* block from the plugin's real block.json, so it compares against what the site registers. Each block's save shape is read off its index.js rather than kept in a list here that would drift.
• .forgejo/workflows/block-validation.yml — runs it twice:
  • what this repo generates (the brand previews, the five theme patterns, the templates and the site's header and footer): must be clean, or the job fails.
  • what came with the third-party theme: reported only. 47 blocks today — invalid core/cover and blocks the Getwid plugins own. Printed so the number stays visible instead of growing quietly.
• .npmrc pins legacy-peer-deps: npm's strict resolver spends minutes backtracking over the @wordpress peer ranges and then rejects them. npm ci reads the file too, so CI cannot forget it.
• Lives under .forgejo/ so the JS stays with CI rather than landing in the repo proper.

Testing

• Against main as it stands: the 31 generated files validate clean; the inherited patterns report 47 blocks and exit 0.
• Failure path checked by putting the #136 bug back — stripping the style from one generated pattern. The job fails and names the file, the block and the attribute:

  core/group is invalid — Expected attributes [["class","wp-block-group alignfull"],["style","padding-top:var(--wp--preset--spacing--lg);…"]], instead saw [["class","wp-block-group alignfull"]]

• npm ci from clean: 3s, 324 packages.
• test_workflow_invariants.py passes on the new workflow (57 tests); yamllint clean; the full suite is 327 passing.

Impact Statement

CI only — no change to any generated artifact, the theme, or the site. Adds one job to pull requests, roughly the cost of npm ci plus a parse of 31 files. It can fail a PR that would otherwise merge, which is the point: the failure it catches is one that reaches readers as a recovery prompt instead of a page.

One caveat, in the README too: these packages track Gutenberg's releases while the site runs the blocks bundled with its WordPress. They agree about the mismatch this exists to catch, but core blocks gain deprecations over time, so a finding against an inherited block may reflect a newer core than the site runs. That is part of why the inherited set only reports.

#136 fixed five pages whose wrappers WordPress would not accept. This is the gate that would have caught them. WordPress rebuilds a block's markup from its attributes and compares the two. When they disagree the editor offers "Attempt Block Recovery", and recovering in the Site Editor saves a copy into the database that then shadows the theme's own file — which is how `/news/` ended up rendering from an override. A mismatch forks the page; it does not stay an editor warning. Nothing here could have caught it. `copy_coverage` counts text, `forgeblock_validate` checks the ForgeBlock contract, and neither knows what WordPress does with a block's attributes. This asks WordPress's own packages. ## Scope - `.forgejo/block-validation/validate-blocks.cjs` — parses markup with `@wordpress/blocks`, registers the core blocks, and registers every `toilville/*` block from the plugin's real `block.json`, so it compares against what the site registers. Each block's save shape is read off its `index.js` rather than kept in a list here that would drift. - `.forgejo/workflows/block-validation.yml` — runs it twice: - **what this repo generates** (the brand previews, the five theme patterns, the templates and the site's header and footer): must be clean, or the job fails. - **what came with the third-party theme**: reported only. 47 blocks today — invalid `core/cover` and blocks the Getwid plugins own. Printed so the number stays visible instead of growing quietly. - `.npmrc` pins `legacy-peer-deps`: npm's strict resolver spends minutes backtracking over the `@wordpress` peer ranges and then rejects them. `npm ci` reads the file too, so CI cannot forget it. - Lives under `.forgejo/` so the JS stays with CI rather than landing in the repo proper. ## Testing - Against `main` as it stands: the 31 generated files validate clean; the inherited patterns report 47 blocks and exit 0. - Failure path checked by putting the #136 bug back — stripping the `style` from one generated pattern. The job fails and names the file, the block and the attribute: > `core/group` is invalid — Expected attributes `[["class","wp-block-group alignfull"],["style","padding-top:var(--wp--preset--spacing--lg);…"]]`, instead saw `[["class","wp-block-group alignfull"]]` - `npm ci` from clean: 3s, 324 packages. - `test_workflow_invariants.py` passes on the new workflow (57 tests); `yamllint` clean; the full suite is 327 passing. ## Impact Statement CI only — no change to any generated artifact, the theme, or the site. Adds one job to pull requests, roughly the cost of `npm ci` plus a parse of 31 files. It can fail a PR that would otherwise merge, which is the point: the failure it catches is one that reaches readers as a recovery prompt instead of a page. One caveat, in the README too: these packages track Gutenberg's releases while the site runs the blocks bundled with its WordPress. They agree about the mismatch this exists to catch, but core blocks gain deprecations over time, so a finding against an *inherited* block may reflect a newer core than the site runs. That is part of why the inherited set only reports.

peterswimm added 1 commit 2026-09-14 18:51:08 +00:00

ci: validate generated markup against Gutenberg's own block validator ... 19ede2c7f7

WordPress rebuilds a block's markup from its attributes and compares the
two. When they disagree the editor offers "Attempt Block Recovery", and
recovering in the Site Editor saves a copy into the database that then
shadows the theme's own file — so a mismatch forks the page rather than
just warning about it. #136 shipped five such pages.

Nothing here could have caught that: copy_coverage counts text,
forgeblock_validate checks the ForgeBlock contract, and neither knows
what WordPress does with a block's attributes. This asks WordPress's own
packages, registering every toilville/* block from the plugin's real
block.json so it compares against what the site registers.

The job holds what this repo generates to a clean bill, and separately
reports the patterns inherited with the third-party theme — 47 blocks
today, invalid core/cover and blocks the Getwid plugins own — so that
number stays visible instead of growing quietly.

npm's strict peer resolver spends minutes backtracking over the
@wordpress ranges and then rejects them, so .npmrc pins legacy-peer-deps
where `npm ci` will read it too.

forge-ci added 1 commit 2026-09-14 18:53:20 +00:00

ci: say which secret is missing when the blocks checkout fails ... b68d356cc8

Toilville_Rituals is private, so the checkout needs CI_TOKEN — and that
secret is not set on this repo. udg-copy-coverage.yml and
test-generator.yml carry the same step and have failed on every run since
at least 2026-09-11 with "Input required and not supplied: token", which
names neither the secret nor the repository.

Let the checkout fail soft and check for the blocks directly, so the log
says what is missing and what to set.

forge-ci added 1 commit 2026-09-14 18:56:52 +00:00

ci: name CI_TOKEN as text, since Forgejo expands the expression anyway 8fabf27eac

forge-ci added 1 commit 2026-09-14 18:58:59 +00:00

ci: check the blocks out with FORGEJO_TOKEN, the org secret that exists ... 65fbd88c91

CI_TOKEN is set on neither toilville-design nor Toilville_Rituals — both
repo secret lists are empty — so every job asking for it fails at
checkout. The Rituals workflows run on FORGEJO_TOKEN, an org-level secret
visible to every repo in the org, this one included. Use that instead of
asking for a credential nobody created.

forge-ci added 1 commit 2026-09-14 18:59:58 +00:00

ci: keep an expression out of the comment that explains expressions ... a8a5ff54d5

Forgejo parses ${{ }} wherever it appears in a run block, comments
included, and an empty one fails to parse — which took the whole workflow
with it (schema validation error, no step run). yamllint and the workflow
invariants both pass on it; only Forgejo's parser objects.

forge-ci added 1 commit 2026-09-14 19:01:30 +00:00

ci: pin the sibling checkout to main ... da6579cd13

Without a ref, the runner resolves the sibling repository at this
workflow's own ref — a branch that exists only here — and checkout reports
"The target couldn't be found".

peterswimm merged commit 9e8e205ae7 into main 2026-09-14 19:02:21 +00:00

peterswimm deleted branch ci/gutenberg-block-validation 2026-09-14 19:02:21 +00:00

peterswimm referenced this pull request from a commit 2026-09-14 19:02:22 +00:00

Merge pull request 'ci: validate generated markup against Gutenberg's own block validator' (#137) from ci/gutenberg-block-validation into main

peterswimm referenced this pull request 2026-09-14 19:07:46 +00:00

ci: ask for CI_TOKEN, the name the other two sibling checkouts use #138

peterswimm referenced this pull request 2026-09-14 21:31:12 +00:00

ci: read the blocks credential from OpenBao instead of a stored secret #139

peterswimm referenced this pull request 2026-09-14 22:38:32 +00:00

ci: resolve the action from the workspace root, and fetch for all three jobs #140

peterswimm referenced this pull request 2026-09-18 18:10:17 +00:00

toilville.com: generated patterns are a content skeleton — fidelity gaps vs the design #102

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

build-dist

Ask the UDG build bot to run just build and commit generated files to this PR

  

priority

P1

Urgent — no working icon yet (custom art pending) or a shipping asset

  

priority

P2

High — has an accessible stand-in; bespoke art wanted

  

priority

P3

Medium — stage visual headers

  

priority

P4

Low — behavioral dimension family

  

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

help wanted

Need some help

  

invalid

Something is wrong

  

question

More information is needed

  

wontfix

This won't be fixed

No labels

build-dist

priority

P1

priority

P2

priority

P3

priority

P4

bug

duplicate

enhancement

help wanted

invalid

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Toilville/toilville-design!137

No description provided.