ci(TWO-25005): add upgrade-smoke — 1.x → HEAD vanilla merchant upgrade#239
ci(TWO-25005): add upgrade-smoke — 1.x → HEAD vanilla merchant upgrade#239dgjlindsay wants to merge 2 commits into
Conversation
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
brtkwr
left a comment
There was a problem hiding this comment.
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 -swith 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 --tagsavoids the API + token entirely and is redundant with the clone that follows. - nit: the verify step's
composer show ... || echo unknownstill passes the!= prior_tagguard 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 10for readiness is flaky-prone under runner load; the sibling di-compile job doesn't sleep. Prefer a readiness poll or drop it.
| 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" |
There was a problem hiding this comment.
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'.
There was a problem hiding this comment.
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 recordssetup_module.schema_version, establishing the FROM state; - HEAD leg: same sequence after re-pointing composer at HEAD —
setup:upgraderuns the cross-major schema/data patches and bumpsschema_version1.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
…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>
53e3884 to
7bb8f56
Compare
What
Adds an
upgrade-smokejob tomagento-pluginCI — the merchant-upgrade coverage this repo was missing (it hadphpstan+di-compileonly).Installs the latest previous-major release (currently 1.16.2) →
module:enable Two_Gateway→di:compile, then swaps to this branch's HEAD (path repo) →composer require two-inc/magento2:*@dev→di:compile, and verifiesTwo_Gatewayis 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 abnupgrade-smokefloors at 2.0.0 and the real 1.x→2.0 abn migration lives indev/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 beforemodule: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.