Skip to content

feat(plugin-lifecycle): add plugin install/uninstall/reinstall lifecycle action#176

Merged
Martin Krzykawski (MartinKrzykawski) merged 6 commits into
mainfrom
feat/plugin-lifecycle-action
Jul 20, 2026
Merged

feat(plugin-lifecycle): add plugin install/uninstall/reinstall lifecycle action#176
Martin Krzykawski (MartinKrzykawski) merged 6 commits into
mainfrom
feat/plugin-lifecycle-action

Conversation

@MartinKrzykawski

@MartinKrzykawski Martin Krzykawski (MartinKrzykawski) commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a composite action plugin-lifecycle that validates a plugin's uninstall/reinstall lifecycle and DAL wiring against an already-installed Shopware — complementing the container-compile gate that setup-extension already provides, i.e. the class of breakage from shopware/shopware#18086 where SwagDynamicAccess compiled on trunk but failed to install on the released version merchants actually ran.

What it does

Run it after setup-extension with install: true (which installs + activates the plugin — that step already gates a plugin that doesn't compile on the target release). This action then:

  1. dal:validate — validates every registered definition + associations against the real schema
  2. plugin:uninstall → assert the configured tables are gone (clean uninstall)
  3. plugin:install --activate → assert tables recreated + re-run dal:validate (working reinstall)

Design notes

  • Composite action, not a reusable workflow — it drops into an existing test job right after setup-extension, reusing the single Shopware install instead of forcing a second one. Matches the granularity of setup-extension / phpunit / versions.
  • tables input is optional — the one plugin-specific bit becomes a caller input; omit it and you still get the uninstall/reinstall + dal:validate checks. Table existence is checked in a small assert-tables.php helper (exact information_schema lookup, reads DATABASE_URL) referenced via ${GITHUB_ACTION_PATH}.
  • Composes with versions for a self-updating version matrix (see the action README).

Testing

  • test.yml gains a plugin-lifecycle-assert-tables job that runs the assert-tables.php helper against a MySQL service — present/absent for an existing and a missing table, plus the empty-table-list no-op. Mirrors the repo's existing helper-script test convention (downstream-wait).
  • The install/uninstall/reinstall command sequence is already proven green in SwagDynamicAccess's own CI (that's where this was extracted from); test.yml deliberately does not boot a full Shopware, matching how the other install-heavy actions are handled here.

Extracted from the SwagDynamicAccess CI so every plugin can reuse it without copy-pasting the bash/PDO lifecycle logic.

…cle action

Add a composite action that validates a plugin's install/uninstall/reinstall
lifecycle and DAL wiring against an already-installed Shopware. It boots the
container (catching a plugin that references core symbols missing on the target
release), runs dal:validate, and optionally asserts the plugin's tables are
dropped on uninstall and recreated on reinstall.

Extracted from the SwagDynamicAccess CI so every plugin can reuse it without
copy-pasting the bash/PDO lifecycle logic.
Add a job to the actions test suite that exercises assert-tables.php against a
MySQL service: present/absent for an existing and a missing table, plus the
empty-table-list no-op. Mirrors the existing helper-script test convention
(downstream-wait).
@MartinKrzykawski Martin Krzykawski (MartinKrzykawski) added the enhancement New feature or request label Jul 20, 2026
Comment thread .github/workflows/test.yml Outdated
Comment thread plugin-lifecycle/README.md
Comment thread plugin-lifecycle/assert-tables.php Outdated
@joberthel
Johannes Berthel (joberthel) requested a review from a team July 20, 2026 12:23
SHOW TABLES LIKE treats _ as a single-char wildcard, so a table name like
swag_dynamic_access_product_rule could match unintended tables. Use an exact
information_schema lookup with a prepared statement instead.
setup-extension (install: true) already installs and activates the plugin, so
the action's leading plugin:refresh + plugin:install were a redundant no-op.
Start from dal:validate and document the install: true precondition; the
uninstall -> reinstall step still exercises the install path.
@MartinKrzykawski
Martin Krzykawski (MartinKrzykawski) merged commit 07442ef into main Jul 20, 2026
10 checks passed
@MartinKrzykawski
Martin Krzykawski (MartinKrzykawski) deleted the feat/plugin-lifecycle-action branch July 20, 2026 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants