The code is tested, the build is green — but have you actually looked inside the zip file your users download? Here is a checklist with seven checks and the exact commands, runnable in 30 seconds.
Updated August 2026 · 5 minute read
In our own project we shipped two versions of a browser extension where the zip was missing the latest bug fixes — while every test was green. Cause: the tests read the core source code; the zip contained a forgotten manual copy. The full story is in the release integrity case study.
The pattern is widespread because it feels safe: the build works, tests are green, so zips get built last and fast. That very last step is the only thing users actually touch.
product-v1.3.7.zip). A file without a version in its name will sooner or later be confused with an old one.1) See exactly what the zip contains (catches junk and missing files):
unzip -l product.zip | sort -k42) Parity check: does the file in the zip match the source? Unpack into a temp dir and compare:
rm -rf /tmp/ziptest && mkdir /tmp/ziptest
unzip -q product.zip -d /tmp/ziptest
diff /tmp/ziptest/core.js src/core.js \
&& echo "PARITY OK" || echo "PARITY FAILED"3) Version sweep: find an old version number inside the artifact:
grep -rn "1\.3\.6" /tmp/ziptest \
&& echo "OLD VERSION IN PACKAGE" || echo "version OK"Put the three steps in a script and call it from your build script as the very last step. If one check fails, the build fails — and nothing ships.
Test what users receive. Everything else — green tests, pretty builds, good intentions — is the road, not the destination. One parity test against the artifact itself would have caught our mistake before a single user saw it.
The same principle applies outside software: the document the customer downloads, the file uploaded to the marketplace, the image shown on the page — open it, look at it, verify it after publishing. It takes minutes and saves trust.
Because your tests run against the source code — not against the artifact. The zip is built by a separate step that can package older files, forget new ones or include junk. A test can only guarantee what it actually loads.
A test that compares the file inside the zip with its source byte-for-byte. If they differ, the build fails. It catches the classic bug where the same code is maintained in two places and one copy gets forgotten at release time.
Yes — that's the whole point. Put the commands in a script and run it as the final step of your build script, before zips get named and uploaded. If any check fails, the build fails and nothing ships.
Stop the release. Find out why the file diverged (manual copy? forgotten build step?), fix the cause — not just the symptom — bump the version number, rebuild, and run the whole checklist once more on the new artifact.