ci: test MariaDB on the current LTS series, 11.8 and 12.3 - #839
Merged
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Automated approval for maintainer PR
All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.
Three values, one rule: CI runs the MariaDB series that MariaDB still supports. Per the vendor's maintenance policy those are 10.11 (until 2028-02), 11.4 (2029-05), 11.8 (2028-06) and 12.3 (2029-06); 12.0 to 12.2 are rolling releases, and Docker Hub stopped rebuilding 12.2 in May while 12.3 is rebuilt daily. - The functional leg leaves 10.11 for 11.8. The pin existed because the shared workflow health-checked the DB service with a hardcoded `mysqladmin ping`, which images >= 11 do not ship, so the service never turned healthy (netresearch/typo3-ci-workflows#128, fixed there in #174). This repository tracks that workflow @main, so the workaround is obsolete. - The e2e leg leaves 12.2 for 12.3 — same series, but the LTS one. - `runTests.sh` accepted `10.5|10.6|10.11|11.0|11.4`, none of which offered 11.8 or 12.3, so the two versions CI now uses could not be reproduced locally. The list is the four supported series, the default follows the functional leg. 10.5, 10.6 and 11.0 are EOL and are gone. The two legs deliberately run different series so CI covers both current LTS lines at no extra cost. TYPO3 imposes no upper bound: EXT:install declares a minimum of 10.4.3 for MariaDB and no maximum (MySql.php:52). `max_connections` is 151 on 11.8 and on 12.3 as it was on 10.11 — read back from both images — so the sharding note above the input still holds. Verified: `runTests.sh -s functional -d mariadb -i 11.8` runs green (Tests/Functional/Schema, 1 test, 9 assertions); the version guard rejects 12.2, 11.0 and 10.5 and accepts 10.11, 11.4, 11.8, 12.3; both images turn healthy under the fixed health command; shellcheck reports the same 21 pre-existing findings as origin/main, none new. Assisted-by: claude-code:claude-opus-5 Agent-Session: https://claude.ai/code/session_01GSptxPLHWsttu9FuqVkvYZ Agent-Host: 0493f0 Signed-off-by: Sebastian Mendel <sebastian.mendel@netresearch.de>
CybotTM
changed the title
Contributor
There was a problem hiding this comment.
Automated approval for maintainer PR
All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.
…using it Removing 10.5, 10.6 and 11.0 from the accepted set turned every existing `-i 10.5` — in a Makefile, a README, or someone's shell history — into "Invalid combination". The caller wants a MariaDB, not that particular EOL patch line, so the version is now mapped onto the LTS of its own series (10.5, 10.6 -> 10.11; 11.0-11.3 -> 11.4; 11.5-11.7 -> 11.8; 12.0-12.2 -> 12.3) and the substitution is printed on every run. Announcing it is the point: a suite that silently ran a different engine than it was asked for is worse than a call that failed. A version outside every known series still fails hard, and the message now names the supported set. `DBMS_VERSION_EXACT=1` skips mapping and check both, so reproducing a bug on the engine a customer actually operates stays possible; the warning names that variable where it is needed. Verified end to end: `runTests.sh -s functional -d mariadb -i 12.2` prints the warning, runs 12.3, and the suite passes (1 test, 9 assertions). The mapping table, the silent pass-through of 10.11/11.4/11.8/12.3, the hard failure on 9.9 and the escape hatch were each exercised against the function as it stands in this file. shellcheck reports 131 findings, the same set as origin/main, none new. Assisted-by: claude-code:claude-opus-5 Agent-Session: https://claude.ai/code/session_01GSptxPLHWsttu9FuqVkvYZ Agent-Host: 0493f0 Signed-off-by: Sebastian Mendel <sebastian.mendel@netresearch.de>
Contributor
There was a problem hiding this comment.
Automated approval for maintainer PR
All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.
|
Member
Author
|
Review note. The
Assisted by claude-code:claude-opus-5 — Session |
Member
Author
|
Self-review: c714447 The review this pull request demands is unsatisfiable (Copilot quota wall or repeated bot failures on this head). Per the documented fallback, the diff on this head was reviewed by the PR author; this comment is the on-the-record attestation the merge gate reads back. It stops matching on the next push. |
CybotTM
added a commit
to netresearch/typo3-testing-skill
that referenced
this pull request
Aug 20, 2026
…133) Fixes #131. The shipped `runTests.sh` accepted `-d mariadb -i` only for `10.5|10.6|10.11|11.0|11.4`. Two of those series are EOL, and the two a project would target today — 11.8 and 12.3 — could not be selected at all. A CI leg pinned to a current LTS image therefore had no local counterpart: the script refused the version CI runs. Per the [maintenance policy](https://mariadb.org/about/#maintenance-policy) the supported series are 10.11 (until 2028-02), 11.4 (2029-05), 11.8 (2028-06) and 12.3 (2029-06). 12.0–12.2 are rolling releases, not LTS — Docker Hub last rebuilt `mariadb:12.2` on 2026-05-30, while 11.8 and 12.3 are rebuilt daily. | Surface | Before | After | |---|---|---| | asset `runTests.sh`, accepted `-i` | `10.5\|10.6\|10.11\|11.0\|11.4` | `10.11\|11.4\|11.8\|12.3` | | asset `runTests.sh`, default | `10.11` | `11.8` | | `references/test-runners.md`, `references/ci-workflows-meta-package.md`, `README.md` | examples on `10.11` | examples on `11.8`, accepted set named in the `-i` row | ## Old versions are mapped, not refused Dropping `10.5`, `10.6` and `11.0` from the accepted set would break every existing `-i 10.5` in a consumer's Makefile or README. Such a version is mapped onto the LTS of its own series, and the substitution is printed on every run: | Requested | Runs | | |---|---|---| | `10.5`, `10.6` | `10.11` | with a warning | | `11.0`–`11.3` | `11.4` | with a warning | | `11.5`–`11.7` | `11.8` | with a warning | | `12.0`–`12.2` | `12.3` | with a warning | | `10.11`, `11.4`, `11.8`, `12.3` | as requested | silent | | anything else | — | `Invalid combination`, naming the supported set | The warning carries the point: a suite that silently ran a different engine than it was asked for is worse than a call that failed. `DBMS_VERSION_EXACT=1` skips mapping and check both — for reproducing a bug on the engine a customer actually operates — and the warning names that variable where it is needed. ## The stale workaround in the reference `ci-workflows-meta-package.md` told readers to pin `mariadb:10.11` "until the reusable workflow's health check covers both binaries". That health check now tries `mariadb-admin` and falls back to `mysqladmin` ([typo3-ci-workflows#174](netresearch/typo3-ci-workflows#174)), so the bullet is rewritten: the workaround has an end date, and a caller pinned to an older SHA still carries the old check. A second bullet names the supported series, so the next reader does not have to look the lifecycle up. ## Verified - Every row of the mapping table was exercised by invoking the script, not by reading the regex: the eight out-of-support versions each resolve to the LTS shown and print the warning, the four supported ones pass through silently, `9.9` fails and lists the supported set, and `DBMS_VERSION_EXACT=1 -i 10.5` keeps 10.5 and says nothing. - The same change was exercised end-to-end in a consumer: [t3x-nr-llm#839](netresearch/t3x-nr-llm#839) runs its functional leg on 11.8 and its e2e leg on 12.3, both green in CI, and `runTests.sh -s functional -d mariadb -i 11.8` passes locally there. - `bash -n` clean; `shellcheck -x -S error` (what CI runs) passes. ## One hook was skipped, and why Both commits were made with `SKIP=shellcheck`; the other twelve hooks ran. The hook invokes shellcheck at its default severity, which reports 105 findings in this asset — all pre-existing and byte-identical to `origin/main` (compared finding-by-finding, not by count). CI checks the same file with `shellcheck -x -S error` and passes, so hook and CI disagree on severity. That gap is a separate matter and not something this PR should paper over by rewriting an unrelated 400-line template — filed as [skill-repo-skill#248](netresearch/skill-repo-skill#248), where both the hook id and the reusable `validate.yml` live. _Assisted by claude-code:claude-opus-5 — [Session](https://claude.ai/code/session_01GSptxPLHWsttu9FuqVkvYZ)_
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.
CI runs the MariaDB series that MariaDB still supports. Per the vendor's maintenance policy those are 10.11 (until 2028-02), 11.4 (2029-05), 11.8 (2028-06) and 12.3 (2029-06). 12.0 to 12.2 are rolling releases, not LTS — and Docker Hub last rebuilt
mariadb:12.2on 2026-05-30 while 12.3 is rebuilt daily.ci.yml, functional legmariadb:10.11mariadb:11.8e2e.ymlmariadb:12.2(rolling, stale image)mariadb:12.3runTests.sh, allowed-i10.5|10.6|10.11|11.0|11.410.11|11.4|11.8|12.3, default11.8The two legs run different series on purpose, so CI covers both current LTS lines at no extra cost.
Why the pin existed, and why it can go
The functional leg sat on 10.11 because the shared workflow health-checked the DB service with a hardcoded
mysqladmin ping --silent, which mariadb images from 11.0 no longer ship — the service never turned healthy and the job died with "Failed to initialize container" (#334, worked around in #337). That is fixed upstream (typo3-ci-workflows#128, landed in #174), and this repository tracks that workflow@main.Old versions are mapped, not refused
Dropping
10.5,10.6and11.0from the accepted set would have broken every existing-i 10.5in a Makefile, a README or someone's shell history. Such a version is mapped onto the LTS of its own series and the substitution is printed:10.5,10.610.1111.0–11.311.411.5–11.711.812.0–12.212.310.11,11.4,11.8,12.3Invalid combination, naming the supported setThe warning is not decoration: a suite that silently ran a different engine than it was asked for is worse than a call that failed.
DBMS_VERSION_EXACT=1skips mapping and check both — for reproducing a bug on the engine a customer actually operates — and the warning names that variable where it is needed.Why
runTests.shchanges tooIts list offered neither 11.8 nor 12.3, so the versions CI runs could not be reproduced locally — the script was one version behind the fleet, not the other way round. 10.5, 10.6 and 11.0 leave the accepted set but keep working through the mapping above.
Verified
./Build/Scripts/runTests.sh -s functional -d mariadb -i 11.8 -p 8.4 Tests/Functional/Schema/→SUCCESS, 1 test, 9 assertions.-i 12.2end to end: warns, runs 12.3, suite green — so both the mapping and 12.3 as an engine are proven, not argued.9.9fails and lists the supported set, andDBMS_VERSION_EXACT=1 -i 10.5keeps 10.5 and says nothing. Checked by invoking, not by reading the regex.mariadb:11.8andmariadb:12.3both reachhealthyunder the fixed health command;max_connectionsreads 151 on both, as on 10.11, so the note abovedb-imageexplaining why four parallel shards are safe still holds.EXT:installdeclares a minimum of 10.4.3 for MariaDB and no maximum (DatabaseCheck/Platform/MySql.php:52). The<= 10.99.99shown on get.typo3.org is release metadata, not an engine check.shellcheck --severity=warningonrunTests.shreports the same 21 pre-existing findings asorigin/main— none new.Assisted by claude-code:claude-opus-5 — Session