Conversation
The `mariadb:11.4` image used by Magento 2.4.9 no longer ships `mysqladmin`, so the existing single MySQL service template (`--health-cmd="mysqladmin ping"`) fails its health check and the `setup-install` lane is torn down at "Initialize containers". A simple swap to `healthcheck.sh --connect --innodb_initialized` would break the `mysql:8.4` lanes (the script is MariaDB-only), so a single template cannot cover both engines. Per @damienwebdev's direction on issue mage-os#365, model MariaDB as its own first-class service, mirroring the existing opensearch/elasticsearch and valkey/redis patterns: - `matrix-type.ts`: add `mariadb: string` to `PackageMatrixVersion` - `service-config.ts`: add `mariadbConfig` with the healthcheck.sh command; leave `mysqlConfig` with `mysqladmin ping` - `build-services.ts`: add `getDatabaseChoice()` that prefers mariadb over mysql; emit either `services.mariadb` or `services.mysql` - version JSON: 22 entries that encoded MariaDB by stuffing the image into the `mysql` field now use a top-level `mariadb` key instead - `build-services.spec.ts`: add a database-selection describe block - `amend-matrix-for-next.spec.ts`: fixtures gain `mariadb: ""` to satisfy the new required field - `.github/workflows/integration.yaml`: port lookup falls back from `job.services.mysql.ports['3306']` to the mariadb key - `supported-version/README.md`: include_services description mentions MariaDB alongside MySQL - `dist/index.js`: rebuilt Fixes mage-os#365 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Mirrors the matrix schema change in `supported-version`: the install action now treats `services.mariadb` as equivalent to `services.mysql` for both the bin/magento setup:install DB flags and the pre-install `SET GLOBAL log_bin_trust_function_creators = 1;` prep statement (supported by both engines). - `build-command.ts`: add `mariadb?` to the `Services` interface and a small `getDatabaseService()` helper that prefers mariadb when both are present - `index.ts`: route the mysql-cli prep call through the same helper - `build-command.spec.ts`: add mariadb-only and mariadb-preferred-over- mysql cases; rename the existing mysql describe block to "database" - `dist/index.js`: rebuilt Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add the mage-os/project-community-edition:3.4.0 entry (upstream Magento 2.4.9) to individual.json and composite.json, and set the previous 3.3.0 line to end-of-life on the 3.4.0 release date (2026-08-11), per the same-day supersede convention. Service requirements are carried over unchanged from 3.3.0: PHP 8.4, Composer 2.10.2, MySQL 8.4, OpenSearch 3, RabbitMQ 4.1, Valkey 8, Varnish 7.7, Nginx 1.28. Also adds the >=3.4 <3.5 composite range and rolls the default and :next entries forward to the 3.4.0 release/EOL dates. dist/index.js rebuilt; all 116 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VEM9r6MBaDUb1TNvfgGbg5
feat(supported-version): add Mage-OS 3.4.0 (Magento 2.4.9)
Brings the branch up to date with main after three months of drift so it can be reviewed and merged. The version JSON files conflicted because this branch re-keyed the MariaDB entries from "mysql" to "mariadb" while main edited the same lines to bump Composer from 2.9.8 to 2.10.2 and to add the Mage-OS 3.1.0, 3.2.0 and 3.3.0 entries. Resolved by taking main's content for those files and re-applying the key rename on top, so the branch keeps its only semantic change to them and none of the newer release data is lost. Verified that the 125 entries across the four files are identical to main apart from the 22 mysql-to-mariadb key renames. Both dist bundles were regenerated from source rather than merged, since merging minified output is not meaningful. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QLy1odBZniuNwyTAh2AYgL
marcelmtz
force-pushed
the
fix/mariadb-service
branch
from
August 19, 2026 15:03
94ffb9e to
9d2b162
Compare
Picks up the Mage-OS 3.4.0 entry added in mage-os#388. Only the generated supported-version bundle conflicted; the version JSON files merged cleanly, since 3.4.0 uses mysql:8.4 and so does not touch any of the entries this branch re-keys to mariadb. Resolved by regenerating both dist bundles from the merged source.
Reverts the temporary mysql:8.4 override from mage-os#377 and moves every Mage-OS 3.x entry back to mariadb:11.4, matching the build spec Mage-OS 3 inherits from upstream Magento 2.4.9. Covers the 3.0.0 through 3.4.0 individual entries, the >=3.0 through >=3.4 composite ranges, and the default and :next aliases, so a given version resolves to the same database however it is requested. Mage-OS 1.x and 2.x are untouched. The override was added because mariadb:11.4 did not work in the release integration checks. The healthcheck bug fixed earlier in this branch is the most likely cause: mariadb:11.4 dropped the mysqladmin binary the health command relied on, so the container never became healthy. These entries now carry the mariadb key and so use healthcheck.sh instead. Note this cannot be verified by this repository's CI, which only builds the magento-open-source matrix. The first real exercise is Mage-OS Nightly in generate-mirror-repo-js, which tracks @main and will switch from mysql:8.4 to mariadb:11.4 as soon as this merges. Refs mage-os#377, mage-os#378
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
2 participants
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.
Validation-only PR against my own fork. Not for merge — this exists to run CI on the exact commit intended for
rhoerr/mage-os.github-actions:fix/mariadb-service(PR mage-os#370) before pushing it there.Ryan's two commits are untouched; this adds one merge commit bringing the branch up to date with
mage-os/github-actions@mainafter three months of drift.Conflict resolution
The four version JSON files conflicted because the branch re-keyed MariaDB entries
mysql→mariadbwhile main edited the same lines (Composer 2.9.8 → 2.10.2, plus the Mage-OS 3.1.0 / 3.2.0 / 3.3.0 entries).Resolved by taking main's content wholesale, then re-applying the key rename on top — safe because the branch's only change to those files is the 22 renames.
Verified both directions:
mysql→mariadbkey renames2.10.2, 59×2.2.28, 9×1, 0×2.9.8) — none of the newer release data was revertedmariadbkeys lost relative to Ryan's tipBoth
dist/index.jsbundles were regenerated from source rather than merged; re-running the builds reproduces them byte-identically.Local checks
npm ci && npm test→ 121 passed (supported-version) + 18 passed (setup-install)magento-open-sourcenightly →services.mariadb/healthcheck.sh --connect --innodb_initializedmage-osnightly →services.mysql/mysqladmin ping🤖 Generated with Claude Code
https://claude.ai/code/session_01QLy1odBZniuNwyTAh2AYgL