runTests.sh asset: MariaDB version list is stale and has drifted across every copy

[CybotTM]

The runTests.sh shipped at skills/typo3-testing/assets/Build/Scripts/runTests.sh accepts -d mariadb -i only for 10.5|10.6|10.11|11.0|11.4. Two of those series are EOL, and the two MariaDB series a project would actually target today — 11.8 and 12.3 — cannot be selected at all. A CI leg pinned to a current LTS image therefore has no local counterpart: the script refuses the version CI runs.

Per the vendor's maintenance policy the supported series are 10.11 (until 2028-02), 11.4 (2029-05), 11.8 (2028-06) and 12.3 (2029-06). 10.5, 10.6 and 11.0 are EOL. 12.0 to 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.

The list has drifted across every copy

Each repository carries its own copy of this script, so the list is now different almost everywhere. Measured today via the contents API:

Repository	Accepted -i for mariadb
netresearch/typo3-testing-skill (this asset)	10.5|10.6|10.11|11.0|11.4
netresearch/t3x-nr-vault	10.5|10.6|10.11|11.0|11.4
netresearch/t3x-nr-repurpose	10.5|10.6|10.11|11.0|11.4
netresearch/nr-landingpage	10.5|10.6|10.11|11.0|11.4
netresearch/t3x-contexts	10.5|10.11|11.4
netresearch/t3x-rte_ckeditor_image	10.2|10.3|10.4|10.5|10.6|10.7|10.8|10.9|10.10|10.11|11.0|11.1
netresearch/t3x-nr-llm	10.11|11.4|11.8|12.3 (fixed in t3x-nr-llm#839)

TYPO3 Core's own Build/Scripts/runTests.sh — the lineage all of these come from — is at 10.4 … 11.4 on main, so the staleness is inherited rather than introduced here. That is the reason to fix it in the asset: the copies will not converge on their own.

Suggested change to the asset

-            [[ -z "${DBMS_VERSION}" ]] && DBMS_VERSION="11.4"
-            if ! [[ ${DBMS_VERSION} =~ ^(10.5|10.6|10.11|11.0|11.4)$ ]]; then
+            [[ -z "${DBMS_VERSION}" ]] && DBMS_VERSION="11.8"
+            # MariaDB series still in community support (mariadb.org maintenance
+            # policy): 10.11 until 2028-02, 11.4 until 2029-05, 11.8 until
+            # 2028-06, 12.3 until 2029-06. 10.5, 10.6 and 11.0 are EOL;
+            # 12.0-12.2 are rolling releases, not LTS.
+            if ! [[ ${DBMS_VERSION} =~ ^(10.11|11.4|11.8|12.3)$ ]]; then

The -i help line names the default and needs the same bump. mysql (8.0|8.4|9.0) and postgres (12|13|14|15|16|17) have the same shape of problem — MySQL 9.0 is superseded by later innovation releases, PostgreSQL 12 and 13 are EOL — but I have not measured those lifecycles and did not touch them.

Verified for the MariaDB part in t3x-nr-llm: runTests.sh -s functional -d mariadb -i 11.8 runs green, the guard rejects 12.2, 11.0, 10.5 and accepts 10.11, 11.4, 11.8, 12.3, and both images turn healthy under the workflow's DB health check.

What this does not solve

The asset is copied, not consumed, so updating it fixes new copies and leaves the six existing ones drifted. Whether the copies get swept, or the script becomes something repos pull in (a composer-installed binary, a shared action), is the open question behind this ticket.

Assisted by claude-code:claude-opus-5 — Session