Auto-rebuild & auto-merge theme-asset Dependabot PRs (+ verify check)

[CybotTM]

Problem

packages/typo3-docs-theme/ commits its built frontend assets — the Vite output under assets/js/ and the Grunt output under resources/public/. Those committed files drift out of sync two ways:

1. A contributor edits the theme sources but forgets to rebuild and commit the output.
2. Dependabot bumps a build dependency of the theme — the build output changes, but Dependabot only updates the dependency; it can't rebuild the assets. (This is what made the manual follow-up [BUGFIX] Rebuilding assets after mergin #1264 necessary.)

What this adds

1. check-built-assets.yaml — on every pull request, rebuilds the theme and fails if the committed assets don't match a fresh build (catches both modified and newly-generated files, one actionable annotation). It runs on every PR and short-circuits to success when the theme package is untouched, so it can be a required status check without blocking unrelated PRs.
2. dependabot-rebuild-assets.yaml — when Dependabot opens a PR that updates a theme dependency, rebuilds the assets, commits them back (GitHub-signed / Verified, via a GitHub App), and enables auto-merge.
3. pr-auto-merge.yaml — the existing generic Dependabot auto-merge is updated to skip these theme-dependency PRs; the workflow above handles them, after the rebuild commit is in place.
4. dependabot.yml — fixes an invalid key (ignored-updates) that currently prevents Dependabot from parsing the config at all. Prerequisite for everything above, and a standalone bug worth fixing regardless.
5. Docs pointer in Documentation/Developer/ThemeCustomization.rst.

Setup the repository must have (settings, not code)

• A GitHub App with Contents: write + Pull requests: write, installed on this repo, exposed as secrets APP_ID / APP_PRIVATE_KEY. (The org already runs one for the backport workflow — reusable-backport.yml uses the same secret names.)
• Allow auto-merge enabled in repo settings.
• Branch protection requiring the verify status check.

Security model

dependabot-rebuild-assets.yaml uses pull_request_target (the same reason pr-auto-merge.yaml already does). Hardening: actor gated to dependabot[bot]; checkout pinned to the PR head SHA; a lockfile-only diff guard (refuse to build if anything but package.json/package-lock.json changed); npm ci --ignore-scripts; harden-runner egress in block mode; the workflow GITHUB_TOKEN is read-only and all writes use the App token; the App token is minted after the build so build code can't read it; the commit is created via the GitHub API (createCommitOnBranch) so it is GitHub-signed and re-triggers verify on the new commit.

Residual risk (accepted, full hands-off chosen): because patch/minor theme bumps auto-merge, a freshly-bumped (potentially compromised) dependency's build-time code runs and its output is merged without a human in the loop. The guards above shrink this (no install scripts, blocked egress, lockfile-only diff, no token exposed to the build) but do not eliminate it. A repo that prefers a checkpoint can drop the "Enable auto-merge" step and merge these PRs manually, or restrict auto-merge to patch-only.

Validation

Proven end-to-end on a fork (CybotTM/render-guides): non-theme PR → verify skips green; stale-theme PR → verify fails and merge is blocked; Dependabot bump → Verified rebuild commit → verify re-runs on that commit → hands-off auto-merge → main left with correct assets. Reviewed across security, syntax, state-of-the-art, and documentation.

Not included

A Node-24 engines/.nvmrc bump was kept out as an unrelated change; happy to send it separately if wanted.

[garvinhicking]

So, "allow auto merge" is enabled. The App secrets should exist. I'm not sure what you mean with "verify status" though.

The only "verify" I can find under branch protection is the one here:

and I don't think we can require that...

[CybotTM]

@garvinhicking

"verify" status check means the "verify" job:

https://github.com/TYPO3-Documentation/render-guides/pull/1265/changes#diff-31e507d3ed5388405d0382e860458b4c02af7444aa1084a8aed89f3c5da70d36R22

It must be required to ensure the PR does not get (auto-)merged when it fails.

You may only be able to set it after merge.

And regarding the "signed commits", IMO they should be required along with signed-off commits.
git commit --gpg-sign --signoff ... (git commit -s -S ...) is not that hard.

You can easily enable it for all commits:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

after registering your ssh key in GitHub → SSH and GPG keys → Signing keys
and your commit email git config user.email must match one of your verified emails in GitHub.

[CybotTM]

I will check failing "Main / Validate monorepo structure (pull_request)Failing after 36s"