chore: improve integration test runs in the CI (build once, reuse across matrix)#2932
chore: improve integration test runs in the CI (build once, reuse across matrix)#2932mojtaba-esk wants to merge 32 commits intomainfrom
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is
❌ Your project check has failed because the head coverage (0.00%) is below the target coverage (40.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #2932 +/- ##
===========================================
+ Coverage 57.76% 66.52% +8.75%
===========================================
Files 2111 6 -2105
Lines 174240 469 -173771
===========================================
- Hits 100653 312 -100341
+ Misses 64631 127 -64504
+ Partials 8956 30 -8926
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
mojtaba-esk
changed the title
| RUN curl -L https://go.dev/dl/go1.25.6.linux-amd64.tar.gz | tar xvzf - -C /usr/local/ | ||
| RUN curl -L https://foundry.paradigm.xyz | bash |
There was a problem hiding this comment.
nit: may be worthwhile to pin this to a specific release. As is, this will take whatever that request returns, which could vary from run to run. Can also validate the checksum for integrity. Reproducibility in practice being the more concerning point to me.
| DOCKER_BUILD_CACHE_TO ?= | ||
| LOCALNODE_BASE_TAG := sei-chain/localnode-base:go1.25.6 | ||
|
|
||
| # Base image (Go, Foundry, Node). Rebuild only when tool versions or Dockerfile.base change. |
There was a problem hiding this comment.
Just a matter of preference: this seems a little misleading on first read. I initially interpreted this as the target enforcing this diff check.
| fi | ||
| .PHONY: build-docker-node-base | ||
|
|
||
| # Build only the app image (requires sei-chain/localnode-base:go1.25.6 to exist locally; used in CI when base is pulled or pre-built) |
There was a problem hiding this comment.
Instead of commenting this dependency, consider codifying it and making the build of the localnode-base a prerequisite or adding a log to make the outcome clear.
| @if [ ! -f build/seid ] || [ ! -f build/price-feeder ]; then \ | ||
| echo "ERROR: build/seid and build/price-feeder must exist. Run the build step first."; exit 1; \ | ||
| fi |
| .PHONY: build-docker-node-app | ||
|
|
||
| # Build app image with prebuilt seid binary (context = repo root; requires build/seid and build/price-feeder to exist). | ||
| # Used in CI: build seid in a container first, then run this target so the image contains the binary. |
There was a problem hiding this comment.
nit: we're building seid in the runner I believe.
| # Build docker image for detected platform (depends on base; app layer is quick) | ||
| build-docker-node: build-docker-node-base |
There was a problem hiding this comment.
This is better since you're explicitly orchestrating dependencies rather than them being in a comment most people (or agents) won't immediately see.
Also, not immediately clear why you'd use a sub-make target for build-docker-node-app. If you do: build-docker-node: build-docker-node-base build-docker-node-app then Makefile analysis tools will be able to better understand make target relationships.
Let me know if I've missed something.
2 participants
Describe your changes and provide context
This PR proposes to build the localnode image once in a dedicated job (base from GHCR or build+push, app with GHA cache, then push to ttl.sh with commit-SHA tag). All 14 matrix test jobs pull that image and run the cluster/tests instead of building. Makefile adds build-docker-node-app and drops proxy/local-only logic; Dockerfiles use ubuntu:25.04.
Testing performed to validate your change (CI Performance Improvement Summary)
Comparison Scope
This compares the Baseline CI architecture vs the *Run after improvements applied (Latest run) *.
Wall Clock Time
Total reduction: 50m 37s (~43.5% faster)
Critical Path (Normalized Comparison)
Since baseline jobs each built their own image, we compare:
Baseline bottleneck:
EVM Interoperability = 14m 17sLatest bottleneck (Build + EVM Interoperability):
2m 17s + 10m 19s = 12m 36sNet improvement on true per-job cost: 1m 41s (~12% faster)
Resource Usage Impact
Baseline:
Latest:
This reduces total runner-minute consumption while also improving wall-clock time.
Summary
While the per-job runtime gain is modest (~1m 41s), the overall CI latency and resource efficiency improvements are substantial.
Note: Timings were collected from the GitHub Actions usage page for this PR only and may vary due to runner load, caching state, and other environmental factors.