Summary
The setup-install matrix lane for magento/project-community-edition:2.4.9 consistently fails at the Initialize containers step with:
Failed to initialize container mariadb:11.4
One or more containers failed to start.
despite MariaDB itself reaching ready for connections … port: 3306 in the container log. Example failing run: https://github.com/mage-os/github-actions/actions/runs/25840481712/job/75925041135
The matrix lanes for 2.4.6-p15, 2.4.7-p10, and 2.4.8-p5 all pass on the same workflow run.
Root cause
The official mariadb:11.4 Docker image no longer ships the mysqladmin binary (upstream announcement). Our service-container template still uses it for the health check:
supported-version/src/services/service-config.ts:18
options: '--health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3'
When this is applied to a MariaDB ≥ 11.x image (currently mapped for Magento 2.4.9 and the catch-all entries in supported-version/src/versions/magento-open-source/composite.json:146, :160, :174), the health command exits non-zero forever, the container is marked unhealthy, and Actions tears the job down. Older lanes are unaffected because they are still pinned to mariadb:10.6, which still includes mysqladmin.
This regression has existed since #358 (which introduced 2.4.9 → mariadb:11.4) and reproduces on every PR, not just the branch where it was first noticed.
Recommendation
Switch the health command to the healthcheck.sh script that ships in both mariadb:10.6 and mariadb:11.4 images, so a single template covers all currently-supported versions:
supported-version/src/services/service-config.ts:18
options: '--health-cmd="healthcheck.sh --connect --innodb_initialized" --health-interval=10s --health-timeout=5s --health-retries=3'
Also update the matching expectation in supported-version/src/services/build-services.spec.ts:119 (currently asserts 'mysqladmin ping') and rebuild dist/.
References
Summary
The
setup-installmatrix lane formagento/project-community-edition:2.4.9consistently fails at the Initialize containers step with:despite MariaDB itself reaching
ready for connections … port: 3306in the container log. Example failing run: https://github.com/mage-os/github-actions/actions/runs/25840481712/job/75925041135The matrix lanes for
2.4.6-p15,2.4.7-p10, and2.4.8-p5all pass on the same workflow run.Root cause
The official
mariadb:11.4Docker image no longer ships themysqladminbinary (upstream announcement). Our service-container template still uses it for the health check:supported-version/src/services/service-config.ts:18options: '--health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3'When this is applied to a MariaDB ≥ 11.x image (currently mapped for Magento 2.4.9 and the catch-all entries in
supported-version/src/versions/magento-open-source/composite.json:146,:160,:174), the health command exits non-zero forever, the container is markedunhealthy, and Actions tears the job down. Older lanes are unaffected because they are still pinned tomariadb:10.6, which still includesmysqladmin.This regression has existed since #358 (which introduced 2.4.9 → mariadb:11.4) and reproduces on every PR, not just the branch where it was first noticed.
Recommendation
Switch the health command to the
healthcheck.shscript that ships in bothmariadb:10.6andmariadb:11.4images, so a single template covers all currently-supported versions:supported-version/src/services/service-config.ts:18options: '--health-cmd="healthcheck.sh --connect --innodb_initialized" --health-interval=10s --health-timeout=5s --health-retries=3'Also update the matching expectation in
supported-version/src/services/build-services.spec.ts:119(currently asserts'mysqladmin ping') and rebuilddist/.References