perf(ci): bake the tools CI keeps fetching from the WAN - #25
Merged
Conversation
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>
…m 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>
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.
Two independent image changes, both driven by measurements taken on the enterprise PR pipeline. Neither needs a pipeline change to take effect.
1.
zstd+pigzin the images that compress CI artifactsThe enterprise pipeline moves large objects through MinIO on every PR — a binary fetched by ~59 steps, a
docker savetar 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, 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 -1tar + zstd -3 -T0and on the 197.6 MiB enterprise binary,
gzip -6took 4.0 s wherepigz -6 -p8took 0.6 s for the same output size.keploy-cialready had zstd and gains pigz, so existing gzip call sites get a multi-threaded drop-in without changing format.keploy-ci-slimruns the download-artifacts steps andkeploy-ci-go-buildruns both the gate build and go-test's build, so those two pay the compression cost and gain both.No call site changes here — this only makes the tools available so the consuming pipelines can switch.
2.
kind,kubectl,helmbaked intokeploy-ci-playwrightEight enterprise lanes —
daemonset-{arm-race,crossapp-contam,go-timefreeze-nocommand,jsse-execrace,overlay-mark,podcache-arm,tls-record-replay}andselfhosted-cloud-replay— pull these three binaries from the public internet on every run: ~73 MiB per lane, ~580 MiB per PR pipeline, on each lane's critical path, and it makes eight lanes depend ondl.k8s.io/kind.sigs.k8s.io/get.helm.shbeing reachable and fast.Same shape as the chromium bake in #22/#24. Every one of those lanes already wraps its fetch in
if ! command -v <tool>, so this takes effect with no pipeline change and degrades safely — a lane running against an older image just downloads them as it does today.Versions match exactly 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.25and confirming all three report those exact versions and that the guards then skip. They are build ARGs so both sides can be moved together on a bump.One enterprise-side companion (separate PR):
daemonset-crossapp-contam-e2eresolved its kubectl fromdl.k8s.io/release/stable.txtat run time, so it silently tracked whatever kubectl was current while its seven sibling lanes all pinned v1.31.0. That is now pinned too, so the baked version cannot change any lane's behaviour implicitly.🤖 Generated with Claude Code
https://claude.ai/code/session_01NjyvZemjEsxzJx9KSohvVL