Batch Compression Report for Developers

Catching a release-ZIP size regression in review

A PR ships a new release ZIP. Drop both the old and new artefact to see the jump and what caused it — no build checkout needed.

Dropped: release-1.4.0.zip, release-1.5.0.zip

filename,format,sizeBytes,compressedSize,entryCount,ratioPercent,largestEntry,largestEntrySize,encrypted,error
release-1.4.0.zip,zip,12582912,9000000,84,28.5%,bundle.js,4194304,false,
release-1.5.0.zip,zip,41943040,38000000,85,9.4%,bundle.js.map,29360128,false,

Diagnosis: one new entry (85 vs 84), ratio dropped, and largestEntry is
now a 28 MB sourcemap that shouldn't ship to production. Reject the PR
or exclude the .map from the release bundle.

Accidental encryption on a public release

A release ZIP shouldn't be password-protected. The encrypted column catches it before users hit a password prompt.

release-2.0.0.zip,zip,8388608,7000000,40,16.5%,app,2097152,true,

encrypted=true on a public release → broken download for everyone.
Re-package without encryption, then re-run the report to confirm
encrypted=false. (To see the cipher: /archive-tools/encrypted-archive-detector)

tar.gz artefacts from the pipeline

If your CI emits .tar.gz, the report identifies them but won't enumerate entries — a reminder that ZIP and tarball artefacts give different depth here.

service-a.tar.gz,gz,5242880,0,0,—,,0,false,
service-b.tar.gz,gz,6291456,0,0,—,,0,false,
frontend.zip,zip,3145728,2400000,310,23.7%,vendor.js,524288,false,

The .zip gets full numbers; the tarballs get format+size only.
For tarball internals in CI, use tar -tzvf in the pipeline step.

Triaging CI cache bloat across builds

Several cached artefacts are filling the runner. Drop them, sort by sizeBytes, and find the worst offender and what's inside it.

Sort batch-compression-report.csv by sizeBytes desc:

build-987.zip,zip,524288000,...,node_modules.tar,...   ← 500 MB, bundled deps
build-986.zip,zip,104857600,...,dist.js,...

build-987 bundled node_modules into the artefact. Fix the cache key or
exclude node_modules. Confirm the extension mix with
/archive-tools/file-type-breakdown.

The CI-equivalent you'd script (no API)

Because there's no API, here's the Node equivalent for a CI gate — the report is for humans; this is for the pipeline.

// CI artefact-size gate (Node + fflate) — the scriptable equivalent
import { unzipSync } from 'fflate';
import { readFileSync } from 'fs';

const buf = readFileSync('release.zip');
const entries = unzipSync(buf);
const total = Object.values(entries).reduce((n, d) => n + d.length, 0);
if (total > 30 * 1024 * 1024) {
  console.error('Artefact too large:', total);
  process.exit(1);
}
// Use the browser report for review; use this for the gate.

There is no programmatic API for the batch report — it's an interactive page only. For CI gates, script the equivalent with fflate (Node) for ZIP/GZIP or zipinfo/7z l in a shell step. The browser tool is for review-time triage, not pipeline automation.

Entry stats are read from the ZIP central directory. A .tar.gz or .7z artefact is detected and named (format=gz / 7z) but shows 0 entries and a — ratio. If your release pipeline emits tarballs and you need entry-level numbers, list them with tar -t / 7z l instead.

These are ZIP containers under the hood, so they're detected as zip and get full entry stats — handy for inspecting a built .jar's class count or an .apk's contents. The filename keeps its real extension; the format column reads zip.

A truncated or corrupt artefact (e.g. a build that died mid-write) throws and becomes an error row with the reason, while the rest of the batch completes. That row is itself a signal that the build step produced a bad archive.

The batch report requires a Pro plan; Free shows an upgrade prompt. For an individual dev wanting CI-grade checks for free, scripting fflate yourself is the no-cost route. The browser tool's value is convenience and privacy at review time.

Per-file caps are 500 MB (Pro) and 2 GB (Pro-media/Developer). A multi-GB monorepo artefact exceeds the cap — analyse it with zipinfo on the build host. Most release ZIPs are well under the cap.

The report has no options and runs with fixed behaviour, so the same archive yields the same row on any machine. Note the report describes archives; it doesn't normalise them. If you need reproducible artefact bytes, normalise timestamps first with /archive-tools/timestamp-normalizer, then report.

The tool reports the files you drop, not a directory tree. Collect the artefacts into one selection. There's no recursive discovery — that's a job for a shell glob feeding a script.

The report flags encrypted=true from the central directory without needing the password — useful to catch a bundle that shouldn't be encrypted. It never decrypts. For the cipher, use /archive-tools/encrypted-archive-detector.

An artefact with tens of thousands of files that relies on ZIP64 may report a short entryCount or size, because the parser reads 32-bit EOCD fields. For node_modules-style artefacts with enormous file counts, verify with a tool that fully supports ZIP64.