version_auto_bump.php: emit matching schema marker when bumping schema-tracked Joomla components #351

New Issue

2026-07-16T18:47:04Z

jmiller commented

2026-07-16 18:47:04 +00:00

Problem

The auto-bump pipeline (version_auto_bump.php, invoked by the template auto-bump.yml on every push to dev/rc/feature/**/patch/**) advances a component's manifest <version> but does not create a corresponding Joomla schema update marker. This produces recurring com_installer schema drift on every consuming repo.

Why it drifts

Joomla's com_installer reports a component's database as out of date when #__schemas.version_id != the manifest <version> (exact equality). Joomla sets #__schemas to ChangeSet::getSchema() = the highest .sql filename in the component's sql/updates/<driver>/ folder. When auto-bump walks the manifest forward (e.g. 01.00.02 -> 01.03.02-dev) without adding a matching <newversion>.sql, the highest marker stays behind and drift is permanent until someone hand-adds markers -- which the next auto-bump immediately outpaces. It is an unwinnable manual treadmill.

Observed

MokoSuiteStoreLocator: live server #__schemas frozen at 01.00.02 while the manifest had auto-bumped to 01.02.40+. Fixed manually (PR #85 in that repo) but the bot re-bumped past the markers twice during the same session (01.03.01-dev, then 01.03.02-dev), proving the loop.

Proposed fix

In version_auto_bump.php, after computing the new version and before committing, for each Joomla extension being bumped whose manifest declares <update><schemas><schemapath type="...">...</schemapath></schemas>:

Resolve the admin-relative schemapath (respecting <administration><files folder="...">) to the real updates dir, e.g. admin/sql/updates/mysql/.
If no <newversion>.sql exists there, write a no-op marker (comment + SELECT 1;, zero DDL) named exactly <newversion>.sql.
Stage it in the same bump commit so the highest marker always equals the manifest version.

Constraints / acceptance criteria

Marker filename must equal the new manifest version exactly (never exceed it -- the Joomla CI marker <= manifest rule fails on overshoot, and an overshoot flips the drift instead of clearing it).
Marker must contain 0 DDL/DML (SELECT 1;) so it can never introduce ChangeSet errors.
Only act on extensions that actually declare a <schemapath> (skip modules/plugins/packages without one).
Idempotent: no-op if the marker already exists.
After a bump, new ChangeSet($db, $folder)->check() reports 0 errors and getSchema() == manifest version.

Context

Auto-bump workflow template: .mokogit/workflows/auto-bump.yml (VERSION: 09.02.00), step "Bump version" -> php ${MOKO_CLI}/version_auto_bump.php.
Reference repo where drift was diagnosed and worked around: MokoConsulting/MokoSuiteStoreLocator PR #85.

Authored-by: Moko Consulting

## Problem The auto-bump pipeline (`version_auto_bump.php`, invoked by the template `auto-bump.yml` on every push to `dev`/`rc`/`feature/**`/`patch/**`) advances a component's manifest `<version>` but does **not** create a corresponding Joomla schema update marker. This produces recurring `com_installer` schema drift on every consuming repo. ### Why it drifts Joomla's `com_installer` reports a component's database as out of date when `#__schemas.version_id` != the manifest `<version>` (exact equality). Joomla sets `#__schemas` to `ChangeSet::getSchema()` = the **highest `.sql` filename** in the component's `sql/updates/<driver>/` folder. When auto-bump walks the manifest forward (e.g. `01.00.02` -> `01.03.02-dev`) without adding a matching `<newversion>.sql`, the highest marker stays behind and drift is permanent until someone hand-adds markers -- which the next auto-bump immediately outpaces. It is an unwinnable manual treadmill. ### Observed MokoSuiteStoreLocator: live server `#__schemas` frozen at `01.00.02` while the manifest had auto-bumped to `01.02.40`+. Fixed manually (PR #85 in that repo) but the bot re-bumped past the markers twice during the same session (`01.03.01-dev`, then `01.03.02-dev`), proving the loop. ## Proposed fix In `version_auto_bump.php`, after computing the new version and before committing, for each Joomla extension being bumped whose manifest declares `<update><schemas><schemapath type="...">...</schemapath></schemas>`: 1. Resolve the admin-relative schemapath (respecting `<administration><files folder="...">`) to the real updates dir, e.g. `admin/sql/updates/mysql/`. 2. If no `<newversion>.sql` exists there, write a no-op marker (comment + `SELECT 1;`, zero DDL) named exactly `<newversion>.sql`. 3. Stage it in the same bump commit so the highest marker always equals the manifest version. ### Constraints / acceptance criteria - Marker filename must equal the new manifest version exactly (never exceed it -- the Joomla CI `marker <= manifest` rule fails on overshoot, and an overshoot flips the drift instead of clearing it). - Marker must contain 0 DDL/DML (`SELECT 1;`) so it can never introduce `ChangeSet` errors. - Only act on extensions that actually declare a `<schemapath>` (skip modules/plugins/packages without one). - Idempotent: no-op if the marker already exists. - After a bump, `new ChangeSet($db, $folder)->check()` reports 0 errors and `getSchema()` == manifest version. ## Context - Auto-bump workflow template: `.mokogit/workflows/auto-bump.yml` (`VERSION: 09.02.00`), step "Bump version" -> `php ${MOKO_CLI}/version_auto_bump.php`. - Reference repo where drift was diagnosed and worked around: `MokoConsulting/MokoSuiteStoreLocator` PR #85. Authored-by: Moko Consulting

jmiller referenced this issue from a commit

2026-07-16 21:53:34 +00:00

fix(version): emit Joomla schema markers on auto-bump [#351 #354]

jmiller referenced this issue

2026-07-16 21:54:28 +00:00

refactor: MokoGitea -> MokoGit migration + workflow-sync repairs (#350 #351 #352 #354 #11 #4) #356

jmiller referenced this issue from a commit

2026-07-16 22:08:40 +00:00

refactor: MokoGitea -> MokoGit migration + workflow-sync repairs (#350 #351 #352 #354 #11 #4)

jmiller commented

2026-07-17 03:24:15 +00:00

Resolved: auto-bump now writes a matching Joomla schema update marker (main #317 create SQL update file on version bump; also cli/version_auto_bump.php writeSchemaMarkers). Closing.

jmiller closed this issue

2026-07-17 03:24:16 +00:00

Sign in to join this conversation.

Priority Medium

Type Feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoCLI#351