ci: fail when the generated config pages drift from core

[oc-tmueller]

Closes the gap that #137, #138 and #142 exposed: these pages are generated, nothing enforced it, and both directions of failure had already happened.

• Hand edits below the marker: I made one in docs: document the OIDC audience parameter #137. It rendered correctly, passed CI, and would have been silently destroyed by the next regeneration.
• Drift from core: web-updater.enabled went undocumented on 10.15 and 10.16 for two releases (docs: sync config.sample.php parameters for 10.16 #138, docs: sync config.sample.php parameters for 10.15 #142).

This regenerates every version from its core branch and fails on any difference.

Why it does not trust exit codes

convert.php exits 0 on both of its own failure paths — unreadable input and unwritable output. So a sample renamed in core would leave the pages untouched, the diff would find nothing, and the job would pass having checked nothing. That is the same class of bug this workflow exists to catch, one level up, so every file is checked before use and the pages actually regenerated are counted and asserted (Regenerated 6 pages across 3 versions.).

Design notes

Loop-driven, not list-driven. The loop iterates content/server/*/, so a new version cannot be added and silently left unchecked. The core branch is resolved by name, falling back to master only for the in-development version — and that fallback is validated against master's own OC_VersionString, so a directory matching no core branch fails loudly rather than being regenerated from the wrong source.

git ls-remote exit 2 ("no such branch") is distinguished from every other failure. Conflating them would let a transient network error resolve 10.16 to master and then fail the diff for a baffling reason.

Not path-filtered. A required check that is skipped reports as perpetually pending and blocks merges — the trap documented at length in lint-pr-title.yml. The cost is that core-side drift surfaces on an unrelated author's PR, so there is also a nightly run to find it first.

Actions policy. PHP comes from the ownCloud-owned owncloudci/php:7.4 container rather than a third-party setup action. Both actions are actions/*, SHA-pinned; checkout uses the same pin already in ci.yml.

One deliberate non-pin: the converter checkout floats on master, because the question being asked is whether the committed pages match what a maintainer running ctd.sh today would produce. Its composer deps are pinned, since the lock file is the generator's own declared contract.

On failure the explanation and full diff go to the job summary, and the regenerated pages upload as an artifact — downloadable rather than copy-pasted out of a log.

Verified by running the job's own script

Extracted the run: blocks and executed them in owncloudci/php:7.4 against four cases:

case	result
in-sync tree	passes, Regenerated 6 pages across 3 versions.
committed hand edit below the marker	fails, with the diff
edit above the marker	passes — the generator preserves that region by design
version directory with no matching core branch	fails: core has no 10.14 branch and master is 11.0, so there is no source for content/server/10.14

Runtime is ~1.5 MB per core clone (--filter=blob:none matters here — a plain --depth 1 --sparse clone still transfers ~30 MB of blobs), three clones per run.

Two things for you to decide

1. Whether to make this a required check. That is a repo-settings call, not something this PR can do. It is only meaningful as a gate if required.
2. Stacking. Based on docs: sync config.sample.php parameters for 10.15 #142, because the check is red on main today and green once 10.15 is in sync. Merge docs: sync config.sample.php parameters for 10.15 #142 first; GitHub will retarget this to main.

🤖 Generated with Claude Code

The base branch was changed.