test(celestia-node-fiber): docker-compose 4-val + bridge showcase scaffold#3288
Open
walldiss wants to merge 1 commit intoevstack:julien/fiberfrom
Open
test(celestia-node-fiber): docker-compose 4-val + bridge showcase scaffold#3288walldiss wants to merge 1 commit intoevstack:julien/fiberfrom
walldiss wants to merge 1 commit intoevstack:julien/fiberfrom
Conversation
…ffold
Adds tools/celestia-node-fiber/testing/docker/, a self-contained
docker-compose stack that brings up four celestia-app validators (each
running an in-process Fibre server), a celestia-node bridge, and a
one-shot init container that registers FSP hosts via valaddr and
funds an escrow. A Go test driver (build tag fibre_docker) connects
to the running stack and exercises the celestia-node-fiber adapter
end-to-end against real 2/3-quorum Fibre.
Why a docker showcase: the in-process testing/showcase_test.go single-
validator setup proves the adapter wires correctly but doesn't
exercise real consensus quorum, inter-validator P2P, multiple Fibre
servers contributing partial signatures, or dns:/// host registry
resolution. The 4-validator docker stack exercises all of those.
Layout:
- Dockerfile.app: celestia-appd + fibre binaries with -tags fibre,ledger
- Dockerfile.bridge: celestia-node bridge with -tags fibre
- compose.yaml: bootstrap → val0..val3 → register → bridge dependency chain
- scripts/init-genesis.sh: 4-validator genesis bootstrap
- scripts/start-validator.sh: per-validator entrypoint (appd + fibre)
- scripts/register-fsps.sh: MsgSetFibreProviderInfo (with dns:/// prefix)
+ escrow funding for the test client
- scripts/start-bridge.sh: bridge init + JWT export to shared volume
- docker_test.go: TestDockerShowcase — host-side Go driver
- README.md: operator instructions + the known-rough edges
Build tag fibre_docker keeps the test out of the default go test
runs since it requires the external docker stack to be up.
The scaffold is documented honestly: it lays out the architecture,
build args, and the iteration points (fibre CLI flag confirmation,
config.toml override robustness, healthchecks, build-cache speedups).
The point of landing it now is to unblock the next iteration step
rather than to claim flawless first-run behavior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 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 |
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
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.
Summary
Adds `tools/celestia-node-fiber/testing/docker/`, a self-contained docker-compose stack and Go test driver that exercises the `celestia-node-fiber` adapter end-to-end against a real 4-validator + 1-bridge Fibre network.
The existing in-process `testing/showcase_test.go` (single-validator) proves the adapter wires correctly but doesn't exercise:
This stack does. The Go test driver (build-tagged `fibre_docker`) reuses the same Upload → Listen → Download flow as the in-process showcase, just pointed at the running compose endpoints.
Layout
```
tools/celestia-node-fiber/testing/docker/
├── Dockerfile.app celestia-appd + fibre binaries (-tags fibre,ledger)
├── Dockerfile.bridge celestia-node bridge (-tags fibre)
├── compose.yaml bootstrap → val0..val3 → register → bridge
├── scripts/
│ ├── init-genesis.sh 4-val genesis bootstrap
│ ├── start-validator.sh per-val entrypoint (appd + fibre server)
│ ├── register-fsps.sh MsgSetFibreProviderInfo (with dns:/// prefix)
│ │ + MsgDepositToEscrow for the test client
│ └── start-bridge.sh bridge init + JWT export to shared volume
├── docker_test.go TestDockerShowcase — host-side Go driver
└── README.md operator instructions + known rough edges
```
Run
```bash
cd tools/celestia-node-fiber/testing/docker
docker compose up -d --build
wait until `docker compose logs register` writes /shared/setup.done
cd ../..
go test -tags 'fibre fibre_docker' -count=1 -timeout 5m ./testing/docker/...
```
Override host endpoints via `FIBRE_BRIDGE_ADDR` / `FIBRE_CONSENSUS_ADDR` env vars if the default `127.0.0.1:26658` / `127.0.0.1:9090` collide.
Build args
Pin to a specific commit via `docker compose build --build-arg CELESTIA_NODE_REF=`.
Honest scope: this is a scaffold
The README lists the iteration points clearly. Each is a known rough edge that the first end-to-end run on your machine will likely surface:
These are documented up front rather than claimed-and-not-true. The value of the scaffold is in unblocking the next iteration step, not in pretending it works flawlessly.
Verified
🤖 Generated with Claude Code