perf(playwright): bake chromium 1234 so enterprise-ui stops downloading it - #24
Merged
Conversation
…ng it
enterprise-ui's dependency update moves @playwright/test from 1.57.0 to 1.62.1,
which changes the chromium revision from 1200 to 1234. This image bakes 1200, so
until it is rebuilt the two are out of step — and the failure mode is silent.
Measured on enterprise-ui with the two out of step: the baked directory is
non-empty but holds 1200, so restore-playwright-cache.sh reports "browsers
already present", skips the MinIO cache, and `npx playwright install` then pulls
~300 MiB from Microsoft's CDN — Chrome 184.3 MiB plus Chrome Headless Shell
114.7 MiB, roughly five minutes, on each of ~16 lanes, all on the critical path.
That is exactly what the install step's comment says will happen ("a slow
pipeline, not a broken one — but it is the signal to rebuild this image"). This
is that rebuild.
Also makes the mismatch detectable instead of inferable. The verify step
asserted only that the browser directory was non-empty, which a stale revision
satisfies — the very thing that let this go unnoticed. It now:
- asserts chromium-* AND chromium_headless_shell-* separately, since
"non-empty" is satisfied by either one alone and a lane needs both;
- writes the baked revision and Playwright version to
.baked-chromium-revision / .baked-playwright-version in the browser cache,
so a consumer can distinguish "browsers are present" from "the browsers this
lockfile wants are present" without having to know how Playwright lays that
directory out.
Verified by building this image locally: chromium-1234 and
chromium_headless_shell-1234 present, markers read back 1.62.1 / 1234,
mongorestore 100.10.0 still works, cache 656M.
Merge order matters, and it is the reverse of what happened here: publish this
image, then move enterprise-ui's pin onto it. enterprise-ui is currently pinned
to 1.57.0 exactly so it keeps hitting the baked path until this lands.
Signed-off-by: slayerjain <shubhamkjain@outlook.com>
slayerjain
added a commit
that referenced
this pull request
Sep 4, 2026
* perf(ci): ship zstd and pigz in the images that compress CI artifacts
The enterprise pipelines move large objects through MinIO on every PR — a
~198 MiB binary fetched by ~59 steps, a ~275 MiB docker save tar fetched by
21, and Go build-cache tarballs that had reached 4.5 GiB (prepare-and-run)
and 6.89 GiB (go-test). All of it goes through single-threaded gzip today,
and that is measurably the slow part rather than the LAN transfer.
Measured on a real 2.1 GB Go build cache, 8 cores:
tar + gzip -1 14.6 s compress 7.8 s decompress 0.54 GiB
tar + zstd -3 -T0 1.3 s compress 1.3 s decompress 0.45 GiB
and on the 197.6 MiB enterprise binary, gzip -6 took 4.0 s where pigz -6 -p8
took 0.6 s for the same output size.
keploy-ci already had zstd; it gains pigz so the existing gzip call sites get
the multi-threaded drop-in without changing format. keploy-ci-slim runs the
download-artifacts steps and keploy-ci-go-build runs both the gate build and
go-test's build, so those are the two that actually pay the compression cost —
they gain both.
No call site changes here: this only makes the tools available so the
consuming pipelines can switch.
Signed-off-by: slayerjain <shubhamkjain@outlook.com>
* perf(playwright): bake kind, kubectl and helm instead of fetching them per lane
Eight enterprise lanes — daemonset-{arm-race,crossapp-contam,
go-timefreeze-nocommand,jsse-execrace,overlay-mark,podcache-arm,
tls-record-replay} and selfhosted-cloud-replay — each pull these three binaries
from the public internet on every run. That is ~73 MiB per lane and ~580 MiB per
PR pipeline, sitting on each lane's critical path, and it makes eight lanes
depend on dl.k8s.io / kind.sigs.k8s.io / get.helm.sh being reachable and fast.
Same shape as the chromium bake in #22/#24. Every one of those lanes already
wraps the fetch in `if ! command -v <tool>`, so this needs no pipeline change to
take effect and degrades safely — a lane running against an older image just
downloads them as it does today.
Versions match what the lanes pin (kind v0.24.0, kubectl v1.31.0, helm v3.16.4),
so behaviour is unchanged; verified by building this layer on
playwright-1.2.25 and checking all three report those exact versions. They are
build ARGs so the pair can be moved together when either side bumps.
Signed-off-by: slayerjain <shubhamkjain@outlook.com>
---------
Signed-off-by: slayerjain <shubhamkjain@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
enterprise-ui's dependency update (keploy/enterprise-ui#1763) moves
@playwright/testfrom 1.57.0 to 1.62.1, which changes the chromium revision from 1200 to 1234. This image bakes 1200, so until it is rebuilt the two are out of step — and the failure mode is silent rather than loud.What it costs today
Measured on enterprise-ui with the two out of step: the baked directory is non-empty but holds 1200, so
restore-playwright-cache.shreports "browsers already present", skips the MinIO cache, andnpx playwright installfalls through to Microsoft's CDN — ~300 MiB per lane (Chrome 184.3 MiB + Chrome Headless Shell 114.7 MiB), roughly five minutes, on each of ~16 lanes, all on the critical path.That is precisely what the install step's own comment predicts: "a slow pipeline, not a broken one — but it is the signal to rebuild this image." This is that rebuild.
Also makes the mismatch detectable
The verify step asserted only that the browser directory was non-empty, which a stale revision satisfies — the very thing that let this go unnoticed. It now:
chromium-*andchromium_headless_shell-*separately, since "non-empty" is satisfied by either alone and a lane needs both;.baked-chromium-revisionand.baked-playwright-versioninto the browser cache, so a consumer can tell "browsers are present" from "the browsers this lockfile wants are present" without needing to know how Playwright lays that directory out.Verified
Built locally from this Dockerfile:
Merge order
The reverse of what happened here: publish this image first, then move enterprise-ui's pin onto it. enterprise-ui is currently pinned to
1.57.0exactly so it keeps hitting the baked fast path until this lands; once aplaywright-*tag ships with 1.62.1 I'll follow up there with the image tag + pin bump.