Idea
Now that nearly every examples/* directory has a runnable daemon.toml and the cloud-sink examples ship a standalone docker-compose.yml (#947) with documented run steps, we could reuse them as end-to-end tests instead of maintaining a separate e2e fixture set.
Why
- The examples are already exercised manually and kept in sync with the code; turning them into tests gives that coverage for free and keeps the examples honest (a broken example fails CI).
- The standalone composes (LocalStack for
aws_*, Pub/Sub emulator for gcp_pubsub, echo servers for webhook_basics/gcp_cloudfunction, plus the existing kafka/redis/rabbitmq/elasticsearch/postgres composes) already stand up the backing services and provision resources — exactly what an e2e harness needs.
- Each was just verified end-to-end (object written to S3, messages enqueued in SQS,
lambda.Invoke => 200, message pulled from a Pub/Sub subscription, POSTs received by the echo servers), so the assertions are known-good.
Sketch / open questions
- Per example:
docker compose up -d → run Oura against daemon.toml for a bounded time → assert the sink received output (the same inspect commands already in each README) → tear down.
- Most examples intersect mainnet
Tip, so a run needs network and a fresh block (~20s). Worth considering a deterministic local source (e.g. a Dolos/U5C fixture or a recorded N2N stream) so tests don't depend on live mainnet.
- Keep it
workflow_dispatch-only at first (the current e2e is manual and intentionally not a release gate) and only promote to a gate once it's stable.
- Examples we can't bundle standalone (
dolos_source, hydra, mithril) stay out of scope.
Follow-up to #943 / #947.
Idea
Now that nearly every
examples/*directory has a runnabledaemon.tomland the cloud-sink examples ship a standalonedocker-compose.yml(#947) with documented run steps, we could reuse them as end-to-end tests instead of maintaining a separate e2e fixture set.Why
aws_*, Pub/Sub emulator forgcp_pubsub, echo servers forwebhook_basics/gcp_cloudfunction, plus the existing kafka/redis/rabbitmq/elasticsearch/postgres composes) already stand up the backing services and provision resources — exactly what an e2e harness needs.lambda.Invoke => 200, message pulled from a Pub/Sub subscription, POSTs received by the echo servers), so the assertions are known-good.Sketch / open questions
docker compose up -d→ run Oura againstdaemon.tomlfor a bounded time → assert the sink received output (the same inspect commands already in each README) → tear down.Tip, so a run needs network and a fresh block (~20s). Worth considering a deterministic local source (e.g. a Dolos/U5C fixture or a recorded N2N stream) so tests don't depend on live mainnet.workflow_dispatch-only at first (the current e2e is manual and intentionally not a release gate) and only promote to a gate once it's stable.dolos_source,hydra,mithril) stay out of scope.Follow-up to #943 / #947.