fix(devnet): scope the ha-el reth overrides, and keep .claude out of the build context - #1059
Conversation
docker-compose-reth.yml carried reth overrides for ha-el-0/1/2 on the
assumption that compose would ignore them unless
docker-compose-cluster.yml was layered in as well. It does not: compose
creates any service a later -f file names, whether or not an earlier
file declared it. So `make devnet-up-reth` also started three ha-el-*
containers, which only got the -f file's own ha-nodekey mount and none
of the /genesis.json or /jwt-secret.txt mounts that live in the cluster
file. All three died immediately with
error: Invalid value '/genesis.json' for --chain <CHAIN_OR_PATH>:
No such file or directory
Move those three service overrides into docker-compose-cluster-reth.yml
and pass it only when both --cluster and reth are asked for, so the
plain reth devnet now resolves to exactly the geth devnet's service
list. The cluster path is unchanged: ha-el-* still come up on the reth
image and entrypoint with the cluster's mounts intact.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change moves HA Reth services into a dedicated cluster Compose override. Makefile and Python devnet configuration include this override only for cluster Reth runs. Tests and documentation reflect the new Compose layering. ChangesCluster Reth override flow
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change limits HA execution clients to cluster-enabled Reth devnets while preserving cluster behavior and cleanup. No actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 42.86% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 2 files. (4 skipped: 4 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Claude Code keeps its git worktrees under .claude/worktrees. On a machine that has used one, .claude is 1.0 GB -- comparable to .git (1.1 GB) and prover (1.2 GB), both of which .dockerignore already excludes. Nothing under it is ever needed by a build, so every image build was shipping it as build context: ~3.0 GB transferred where ~2.0 GB is required.
Problem
make devnet-up-rethstarted three containers that immediately died:docker-compose-reth.ymlcarried reth overrides forha-el-0/1/2behind this comment:That is not how compose merges files. A service named by any
-ffile is created, whether or not an earlier file declared it — there is no "override-only" form of a service definition. So in the non-cluster devnet those threeha-el-*entries were not overrides of anything; they were full service definitions consisting of only what the reth file happened to specify: an image, an entrypoint, a command with--chain=/genesis.json, and a singleha-nodekeyNmount. The/genesis.jsonand/jwt-secret.txtmounts live indocker-compose-cluster.yml, which is not loaded in that mode, so reth had no chain spec to read and exited before doing anything else.Nothing on the sequencer path breaks as a result — this is why it went unnoticed — but every
devnet-up-rethleaves three failed containers and three stray datadir volumes behind, anddocker compose upreports the failures.Fix
Move the three
ha-el-*reth overrides into a newdocker-compose-cluster-reth.yml, layered only when both--clusterand reth are requested, inMakefileand indevnet.compose_file_args. The plain reth devnet now resolves to exactly the geth devnet's service list; the cluster path is unchanged.Also corrects the same wrong claim where it is repeated in
ops/README.mdand in the two code comments that restate it.Verification
docker compose config --services, all four combinations:morph-el-0/1,node-0/1,tx-submitter-0,gas-price-oracle,layer1-*ha-el-0/1/2)ha-el-0/1/2,ha-node-0/1/2The cluster override still applies — merged
ha-el-*inreth + cluster:make -n devnet-downper mode resolves to the intended-flists, andDEVNET_CLEAN_COMPOSE_FILEScovers the new file sodevnet-clean-buildstill reaps cluster leftovers.python3 -m unittest discover -s ops/devnet-morph/tests— 14 tests, all pass. Three are new or reworked:test_reth_compose_leaves_cluster_services_to_the_cluster_reth_file— regression guard:docker-compose-reth.ymlmust not nameha-el-*at all.test_cluster_reth_compose_overrides_the_ha_execution_clients— the new file carries all three, with the reth image/entrypoint and one key mount each, and does not redefinemorph-el-*.test_reth_compose_configures_deterministic_peering— narrowed to the twomorph-el-*that remain in that file.End-to-end:
make devnet-clean-build && make devnet-up-rethon a wiped devnet brings upmorph-el-0/1,node-0/1,tx-submitter-0,gas-price-oracleand the threelayer1-*containers, with no
ha-el-*container created and nothing inExitedstate (before thischange the same command left three
Exited (2)).morph-el-0produces blocks normally.Note
morph-el-1sits at height 0 for the first ~10 minutes after startup, untiltx-submitter-0commits its first batch —node-1runs withMORPH_NODE_DERIVATION_VERIFY_MODE=layer1, so L1 derivation is its only source of blocks.That behaviour is unrelated to this change and is present on
maintoo; it is being lookedat separately.
Second commit: exclude
.claudefrom the docker build contextRebuilding
morph-node:latestwhile diagnosing an unrelated devnet problem showed thebuild context climbing past 20 GB before any build step ran.
.dockerignoreexcludes.git(1.1 GB) andprover/(1.2 GB), but not.claude/— which is 1.0 GB on anymachine that has used a Claude Code worktree (
.claude/worktrees):Nothing under
.claude/is read by a build. One line in.dockerignore, next to theother excluded top-level directories, plus the matching assertion in the existing
test_root_dockerignore_excludes_generated_build_outputs. Context after this changemeasures 1.74 GB, in line with the ~2.0 GB the repo needs.
(The 20 GB figure itself is not fully explained by this one directory and is not claimed
to be:
ops/docker/.devnetholds four 4 GB sparse mdbx files — 16 GB logical, ~1 MB ondisk — but a targeted
COPYprobe confirms.dockerignoredoes exclude that path, sosomething else contributed. Excluding
.claude/is correct on its own merits either way.)