Skip to content

chore(ci): verify the assets entrypoints.json actually points at - #173

Draft
Björn Meyer (BrocksiNet) wants to merge 1 commit into
mainfrom
chore/zip-guard-verify-entrypoint-targets
Draft

chore(ci): verify the assets entrypoints.json actually points at#173
Björn Meyer (BrocksiNet) wants to merge 1 commit into
mainfrom
chore/zip-guard-verify-entrypoint-targets

Conversation

@BrocksiNet

Copy link
Copy Markdown
Contributor

What

Closes a hole in bin/ci-assert-zip-admin-bundle.sh: it never checked that the assets
entrypoints.json points at are actually in the archive.

Not urgent — the current release artifact is fine, verified by hand. This just makes the
guard cover the last way the original bug's failure mode could recur.

Why

The guard was written against a build that emitted only unhashed filenames. The release
build emits content-hashed assets with an unhashed alias beside them:

administration/js/swag-agentic-commerce-PMJ7ZT4L.js   <- entrypoints.json points here
administration/js/swag-agentic-commerce.js            <- unhashed alias
administration/.vite/entrypoints.json

Those feed two different consumers:

Lane Resolves Reads entrypoints.json?
6.5 / 6.6 administration/js/{technicalName}.js by convention no
6.7 whatever entryPoints[...].js names yes

The guard checked the unhashed path is a real bundle, and separately that the js list is
non-empty — but never that the named file exists. An archive whose hashed target was
missing or misnamed passed the guard and then 404'd on 6.7, silently, in exactly the way
the bug this guard exists to catch was silent.

How

  • Resolve every asset (js + css) referenced by entrypoints.json and assert each ships.
  • Assert the js entry 6.7 actually executes is the compiled bundle, not just the alias.
  • Keep the existing unhashed-path checks for 6.5/6.6.

Output now names both paths so a CI log says which lane loads what:

OK: 6.5/6.6 load js/swag-agentic-commerce.js (97198 bytes);
    6.7 loads /bundles/swagagenticcommerce/administration/js/swag-agentic-commerce-PMJ7ZT4L.js (97198 bytes);
    all 2 referenced assets ship.

Deliberately not asserting the hashed and unhashed copies are byte-identical. They are
today (1346ca66… for both js and css), but shopware-cli is free to emit the alias
differently and the "is this the real bundle" checks already catch the failures that matter.

Testing

Run against four real archives plus one synthesised:

Archive Result
Release artifact from run 31175934692 (hashed + unhashed) pass
Local esbuild build (unhashed only) pass
The shipped-broken 1.2.0 zip fail — 2382-byte shim
Vite-only zip fail — 2382-byte shim
Release artifact with the hashed target deleted, alias intact fail (new) — old guard reported OK

That last row is the point of the change. shellcheck -x bin/*.sh bin/lib/*.sh is clean,
matching the shell-lint job.

The zip guard checked the unhashed js/<name>.js path and, separately, that
entrypoints.json listed at least one js entry. It never checked that the file
the entry names is in the archive.

Those are not always the same file. The release build emits content-hashed
assets (js/<name>-PMJ7ZT4L.js) with an unhashed alias beside them: 6.5 and 6.6
construct the unhashed path by convention and never read entrypoints.json, while
6.7 follows entrypoints.json to the hashed one. So an archive whose hashed target
is missing or misnamed passed the guard and then 404'd on 6.7 — silently, in the
same way the bug this guard exists to catch was silent.

Resolve every asset entrypoints.json references and assert each one ships, and
assert the js entry 6.7 executes is the compiled bundle rather than only checking
the alias.

Deliberately not asserting the hashed and unhashed copies are byte-identical.
They are today, but shopware-cli is free to emit the alias differently, and the
"is this the real bundle" checks already catch the failures that matter.

Verified against four archives: the current release artifact and a local build
pass, the shipped-broken 1.2.0 zip and a vite-only zip still fail, and a
synthesised archive with an intact alias but a deleted hashed target now fails
where the previous guard reported OK.
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.

1 participant