[codeling]

Why

Dependabot can't follow the Joomla versions of the CI matrix (ci.yml) and their checksums (tests/ci/joomla-checksums.sha256, added in #242). Without something watching, the matrix silently falls behind Joomla's security releases.

Change

New workflow .github/workflows/joomla-versions.yml, weekly (Tuesday) and on demand. It reads the releases of joomla/joomla-cms and:

• newer patch release of a version in the matrix (e.g. 5.4.8 -> 5.4.9): opens or updates a pull request on branch joomla-versions that raises the matrix and adds the package's SHA-256. The download's hash must equal the digest GitHub lists for the release asset; if it doesn't, the job fails and changes nothing. If GitHub lists no digest, the PR says so.
• release of a newer minor/major line (e.g. 6.2 when the matrix has 6.1): opens an issue (once per line, also if closed). Supporting a new line is a decision, not a version bump.

Only stable releases with a full package count (no drafts, pre-releases, -elts tags).

tests/ci/joomla-updates.php holds the logic (plan / apply), covered by tests/Unit/JoomlaUpdatesTest.php (15 tests: release filtering, bump vs. new line, the edits, and refusals for other lines, older versions, malformed versions/hashes, duplicates). Documented in tests/README.md.

Things to know

• Old checksum entries stay in the file: the com_bfstop workflow installs through the same file. com_bfstop's matrix is not touched (bfstop only, as agreed).
• CI on the bot's branch: a push made with GITHUB_TOKEN doesn't start pull_request workflows, so the job starts ci.yml on the branch with workflow_dispatch (hence actions: write). The runs show on the branch's commit and thus in the PR. A PAT or app token would make this unnecessary, but needs a secret.
• Repository setting: "Allow GitHub Actions to create and approve pull requests" (Settings -> Actions -> General) must be on for the PR step; otherwise the job fails at gh pr create.
• Trust: the hash comes from the GitHub release, not from Joomla's page; the PR body asks the reviewer to compare MD5/SHA1 with downloads.joomla.org.
• Action references are pinned to the same commits as in CI: pin the GitHub Actions to commit SHAs #241.

Tested

• Unit tests pass (119, 21 skipped because no component checkout here).
• The workflow's three run blocks were executed locally against a throwaway git remote with a fake gh and curl: first run (branch pushed, PR + issue + CI dispatch requested, files as expected, check-joomla-checksums.php passes on the result); second run with the same plan (does nothing: no push, no PR, no dispatch); digest mismatch (fails with an error, nothing committed); API without digest (PR text says so).
• Not tested against the real GitHub API (blocked from my environment): the first scheduled/manual run is the real test. Use "Run workflow" after merging to try it; it does nothing while the matrix is current.

---

Generated by Claude Code

[codeling]

The failing integration jobs (Joomla 5.4.8 on postgres:12 and mariadb:10.11; I'm checking the other jobs as they finish) all fail on one test, ComponentTest::testEntriesOfTheEditFormsAreStoredInCanonicalForm (203.0.113.77/24 was stored instead of 203.0.113.0/24). It is not caused by this PR, which only adds a workflow, a CI script and docs.

The test came in with #240 (merged a few minutes ago). It needs the component side of that change, codeling/com_bfstop#21, which is not merged yet. The CI jobs install com_bfstop from its main, and main still has the old table check() code. That PR is green and mergeable; once it is merged, a re-run of these jobs should pass. Every bfstop PR and main itself will show this failure until then (#241 too).

I can't merge com_bfstop#21 myself. No code change is needed here, so I'm not pushing anything. I'll re-run the failed jobs once it has merged.

---

Generated by Claude Code