Skip to content

ci(TWO-25005): add upgrade-smoke — 1.x → HEAD vanilla merchant upgrade#239

Open
dgjlindsay wants to merge 2 commits into
stagingfrom
doug/two-25005-magento-plugin-upgrade-smoke
Open

ci(TWO-25005): add upgrade-smoke — 1.x → HEAD vanilla merchant upgrade#239
dgjlindsay wants to merge 2 commits into
stagingfrom
doug/two-25005-magento-plugin-upgrade-smoke

Conversation

@dgjlindsay

Copy link
Copy Markdown
Contributor

What

Adds an upgrade-smoke job to magento-plugin CI — the merchant-upgrade coverage this repo was missing (it had phpstan + di-compile only).

Installs the latest previous-major release (currently 1.16.2) → module:enable Two_Gatewaydi:compile, then swaps to this branch's HEAD (path repo) → composer require two-inc/magento2:*@devdi:compile, and verifies Two_Gateway is enabled + the resolved version moved off the prior tag.

Why here (and not the ABN overlay)

The 1.x→2.0 upgrade is the valid, important test for vanilla two-inc/magento2: it's the same package name across majors (1.16.2 and 2.1.1), so a clean same-package cross-major upgrade. In the ABN overlay that same jump is a package rename + monorepo split (TWO-25001) — which is why the abn upgrade-smoke floors at 2.0.0 and the real 1.x→2.0 abn migration lives in dev/upgrade-harness. This PR puts the cross-major coverage where it composes cleanly.

Shape

Mirrors the abn upgrade-smoke: discover prev-major tag (skip with a visible ::warning:: if none), install prior via a path repo, rmdir force-clear before module:enable (TWO-25003), re-point the same repo key at HEAD, verify.

Single leg (Magento 2.4.6 / PHP 8.2) — smoke, not a matrix.


🤖 Generated with Claude Code — opened on Doug's behalf.

@gemini-code-assist

Copy link
Copy Markdown

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

@brtkwr brtkwr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed adversarially for honest-CI. Good bits: prev-major discovery is dynamic and correct (floors at the latest 1.x, not hardcoded), the swap genuinely reinstalls HEAD (repo re-point + @dev + generated-clear, and version 2.1.x != prior tag makes the guard legitimate), the single leg is surfaced in the job name/body, and token handling + the git-ls-files|tar upload are clean.

One thing to resolve before merge (inline on the HEAD step) plus a few nits:

  • nit: the prior-release resolve uses curl -s with no --fail, so a transient GitHub API error yields empty JSON -> LATEST_TAG='' -> skip=true -> the whole job goes green having tested nothing. Add --fail, and consider failing (not skipping) on a genuine API error vs a real no-prev-major.
  • nit: single-page tag fetch (per_page=100) will silently start missing the previous-major tag once the repo exceeds 100 tags; git ls-remote --tags avoids the API + token entirely and is redundant with the clone that follows.
  • nit: the verify step's composer show ... || echo unknown still passes the != prior_tag guard when composer show fails (module:status is the real assertion, so low impact, but the version guard self-defeats on error).
  • nit: the fixed sleep 10 for readiness is flaky-prone under runner load; the sibling di-compile job doesn't sleep. Prefer a readiness poll or drop it.

Comment thread .github/workflows/ci.yml Outdated
docker exec magento-project-community-edition /bin/bash -c \
"rm -rf /data/generated/code /data/generated/metadata /data/var/cache /data/var/page_cache" || true
docker exec magento-project-community-edition ./retry \
"php bin/magento module:enable Two_Gateway && php bin/magento setup:di:compile"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: both the prior-release step and this HEAD step run module:enable Two_Gateway && setup:di:compile but never bin/magento setup:upgrade, so the cross-major schema/data patches and the setup_module.schema_version 1.x -> HEAD transition are never exercised - which is exactly the surface an upgrade-smoke is meant to protect. As written this is close to a fresh-HEAD install + di:compile, which the existing di-compile job already does (and that one does run setup:upgrade). Suggest adding setup:upgrade to at least the HEAD leg, or narrowing the PR's coverage claim so the green check isn't read as 'the 1.x->HEAD DB upgrade is tested'.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — you're right, that was the actual gap. Both legs now run setup:upgrade:

  • prior leg: module:enable && setup:upgrade && setup:di:compile — installs the 1.x schema and records setup_module.schema_version, establishing the FROM state;
  • HEAD leg: same sequence after re-pointing composer at HEAD — setup:upgrade runs the cross-major schema/data patches and bumps schema_version 1.x → HEAD.

So the green check now genuinely covers the 1.x→HEAD DB upgrade, not just a fresh-HEAD install. Pushed as a separate commit.

— posted by Claude on Doug's behalf

dgjlindsay and others added 2 commits July 4, 2026 23:59
…rchant upgrade

magento-plugin had no upgrade coverage (phpstan + di-compile only). Add an
upgrade-smoke that installs the latest previous-major release (currently 1.16.2)
then composer-requires this branch's HEAD and re-runs di:compile — proving the
cross-major 1.x -> 2.x vanilla merchant upgrade lands cleanly on every PR.

two-inc/magento2 keeps the same package name across majors (no rename/split like
the ABN overlay, TWO-25001), so this is a clean same-package upgrade and the
right home for real 1.x -> 2.0 coverage. Mirrors the abn job shape: discover
prev-major tag (skip visibly if none), install prior via path repo, rmdir
force-clear before module:enable (TWO-25003), re-point the repo at HEAD, verify
Two_Gateway enabled + version moved off the prior tag.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bharat review: the job installed the prior release and HEAD and ran
di:compile on each, but never setup:upgrade — so the cross-major DB
schema/data patches and the setup_module.schema_version 1.x->HEAD
transition (the surface an upgrade-smoke exists to protect) were never
exercised. As written it was close to a fresh-HEAD install + di:compile,
which the di-compile job already covers.

Add setup:upgrade to both legs: the prior leg to establish the 1.x
schema_version FROM state, the HEAD leg to run the actual cross-major
migration.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@dgjlindsay dgjlindsay force-pushed the doug/two-25005-magento-plugin-upgrade-smoke branch from 53e3884 to 7bb8f56 Compare July 4, 2026 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants