test: adds cucumber integration tests to CI - #779
Open
hansieodendaal wants to merge 6 commits into
Open
Conversation
hansieodendaal
changed the title
hansieodendaal
marked this pull request as draft
August 21, 2026 12:55
hansieodendaal
force-pushed
the
ho_cucumber_ci
branch
2 times, most recently
from
August 23, 2026 14:49
0574efd to
c71f30b
Compare
…lves issue logos-blockchain#774. #### Changes - Added .github/workflows/cucumber-integration-tests.yml - Runs on PRs and pushes to dev/main - Uses workflow concurrency cancellation - Reuses the existing LEZ CI image - Runs the Cucumber suites on a single ubuntu-latest runner - Builds the Cucumber test target before scenario execution - Executes four sequential suites with scenario concurrency set to 1: - @smoke_ci - @auth_transfer_ci - @indexer_state_ci - @multi_sequencer_ci - Uploads the Cucumber JUnit report - Added reusable run-cucumber-suite action using run-in-ci-image - Preserves LEZ’s Docker-aware execution model - Uploads suite diagnostics on failure - Preserves test failures after artifact upload - Updated run-in-ci-image to persist Cargo git state and Logos blockchain build/cache state between disposable CI containers. - Fixed source-bearing thiserror display messages in integration_tests/src/cucumber/error.rs. - Fixed accidental indentation in block_publisher.rs.
hansieodendaal
force-pushed
the
ho_cucumber_ci
branch
from
August 23, 2026 17:33
c71f30b to
7a21e1f
Compare
hansieodendaal
marked this pull request as ready for review
August 23, 2026 17:33
Contributor
Author
|
General question (@moudyellaz, @Arjentix, @erhant): Should we retire the legacy integration tests that are covered by this initial cucumber CI? |
Collaborator
I don't mind leaving them for now. Maybe once we port all tests we can remove rust integration tests. |
Collaborator
|
@hansieodendaal I can see this job took pretty much an hour. While we made efforts to make our CI as fast as possible (see other jobs in this PR). Can we speed up this job? |
Arjentix
reviewed
Aug 25, 2026
Contributor
Author
Tackling issue #773 should speed up this entire process build-wise. After that it will come down to test optimization and possible concurrency usage (#779 (comment)). GitHub provided runners are also not the fastest under load. |
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Aug 25, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for the Bedrock node used by tests and local Docker setup. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ensures that TF, Cucumber, legacy integration tests, and Docker-backed tests all use a node corresponding to the same Logos revision LEZ is compiled against. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The revision resolved by Cargo is authoritative: ```mermaid flowchart TD A["Cargo.toml<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>node release?"} C -->|Yes| D["Download matching asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["bedrock/.resolved/<br/>logos-blockchain-node"] E --> F F --> G["TF / Cucumber"] F --> H["Legacy integration tests"] F --> I["Docker / local Bedrock"]
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Aug 25, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for the Bedrock node used by tests and local Docker setup. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ensures that TF, Cucumber, legacy integration tests, and Docker-backed tests all use a node corresponding to the same Logos revision LEZ is compiled against. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The revision resolved by Cargo is authoritative: ```mermaid flowchart TD A["Cargo.toml<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>node release?"} C -->|Yes| D["Download matching asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["bedrock/.resolved/<br/>logos-blockchain-node"] E --> F F --> G["TF / Cucumber"] F --> H["Legacy integration tests"] F --> I["Docker / local Bedrock"] ``` There is no separately maintained Bedrock Docker version that can drift from LEZ's Cargo dependency graph. #### ⚙️ Approach #### Resolve the Cargo-pinned Bedrock node A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all Logos packages resolve to one revision; 4. checks published Logos Blockchain releases for an exact matching commit; 5. downloads and verifies the appropriate release asset when one exists; 6. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver produces: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` The metadata records the resolved revision and whether the binary came from a release or a source build. For a Cargo revision without a matching published node binary, the source-build path remains the deterministic fallback. #### Reuse the resolved node in CI Both existing CI paths now resolve the Bedrock node before running tests: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock resolver"] A --> C["Existing test pre-build"] B --> D["Resolved node artifact"] D --> E["Legacy integration tests"] D --> F["TF-based tests"] D --> G["Docker-backed tests"] subgraph CU["Cucumber workflow"] H["Bedrock resolver"] --> I["Cucumber tests"] end ``` The General and Cucumber workflows remain separate top-level workflows, so each resolves the node independently. Within each workflow, the resolved node is reused by its downstream consumers rather than being rebuilt by individual tests. TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build path. #### Keep Cucumber and nextest separate Cucumber remains on its existing Cargo/Cucumber execution path. This PR does **not**: - add the Cucumber custom-harness target to the nextest archive; - execute Cucumber through nextest; - combine the General and Cucumber workflows. Sharing the `integration_tests` compilation between nextest and Cucumber can be considered separately as a CI optimization. #### Use the same node in Docker-backed tests The legacy Bedrock Docker setup no longer independently selects `0.2.1-lssa`. Instead, the Docker runtime contains the same resolved node binary used directly by TF: ```mermaid flowchart LR A["Cargo-resolved<br/>logos-blockchain-node"] A --> B["TF<br/>direct execution"] A --> C["LEZ Bedrock<br/>runtime image"] C --> D["/usr/bin/<br/>logos-blockchain-node"] ``` This removes the second Bedrock version authority while preserving the existing LEZ Bedrock configuration and launch contract. #### Local development A local resolver path is also provided: ```bash just resolve-bedrock-node ``` `just run-bedrock` uses the same Cargo-authoritative node resolution rather than relying on a separately maintained Docker image version. #### 🧪 How to Test Verify the resolver behavior: - Cargo metadata resolves all Logos dependencies to one revision; - a matching published release is downloaded and its SHA-256 verified; - a revision without a matching release falls back to an exact-revision source build; - `bedrock/.resolved/logos-blockchain-node` and `metadata.json` are produced. Verify the CI consumers: - legacy integration tests; - TF-based integration tests; - Docker-backed `test_fixtures` / `TestContext` tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report the resolved Logos revision and whether the binary was downloaded or built from source. #### ✅ Result After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ▼ one resolved node binary ┌────┼─────┐ ▼ ▼ ▼ TF Cucumber Docker/local ``` Updating the Logos dependency used by LEZ is sufficient to update the Bedrock node used everywhere. If an exact matching release binary exists, it is downloaded and verified. If not, the exact Cargo-resolved revision is built from source. #### 🚫 Out of Scope This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow artifact or cache sharing.
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Aug 26, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for the Bedrock node used by tests and local Docker setup. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ensures that TF, Cucumber, legacy integration tests, and Docker-backed tests all use a node corresponding to the same Logos revision LEZ is compiled against. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The revision resolved by Cargo is authoritative: ```mermaid flowchart TD A["Cargo.toml<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>node release?"} C -->|Yes| D["Download matching asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["bedrock/.resolved/<br/>logos-blockchain-node"] E --> F F --> G["TF / Cucumber"] F --> H["Legacy integration tests"] F --> I["Docker / local Bedrock"] ``` There is no separately maintained Bedrock Docker version that can drift from LEZ's Cargo dependency graph. #### ⚙️ Approach #### Resolve the Cargo-pinned Bedrock node A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all Logos packages resolve to one revision; 4. checks published Logos Blockchain releases for an exact matching commit; 5. downloads and verifies the appropriate release asset when one exists; 6. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver produces: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` The metadata records the resolved revision and whether the binary came from a release or a source build. For a Cargo revision without a matching published node binary, the source-build path remains the deterministic fallback. #### Reuse the resolved node in CI Both existing CI paths now resolve the Bedrock node before running tests: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock resolver"] A --> C["Existing test pre-build"] B --> D["Resolved node artifact"] D --> E["Legacy integration tests"] D --> F["TF-based tests"] D --> G["Docker-backed tests"] subgraph CU["Cucumber workflow"] H["Bedrock resolver"] --> I["Cucumber tests"] end ``` The General and Cucumber workflows remain separate top-level workflows, so each resolves the node independently. Within each workflow, the resolved node is reused by its downstream consumers rather than being rebuilt by individual tests. TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build path. #### Keep Cucumber and nextest separate Cucumber remains on its existing Cargo/Cucumber execution path. This PR does **not**: - add the Cucumber custom-harness target to the nextest archive; - execute Cucumber through nextest; - combine the General and Cucumber workflows. Sharing the `integration_tests` compilation between nextest and Cucumber can be considered separately as a CI optimization. #### Use the same node in Docker-backed tests The legacy Bedrock Docker setup no longer independently selects `0.2.1-lssa`. Instead, the Docker runtime contains the same resolved node binary used directly by TF: ```mermaid flowchart LR A["Cargo-resolved<br/>logos-blockchain-node"] A --> B["TF<br/>direct execution"] A --> C["LEZ Bedrock<br/>runtime image"] C --> D["/usr/bin/<br/>logos-blockchain-node"] ``` This removes the second Bedrock version authority while preserving the existing LEZ Bedrock configuration and launch contract. #### Local development A local resolver path is also provided: ```bash just resolve-bedrock-node ``` `just run-bedrock` uses the same Cargo-authoritative node resolution rather than relying on a separately maintained Docker image version. #### 🧪 How to Test Verify the resolver behavior: - Cargo metadata resolves all Logos dependencies to one revision; - a matching published release is downloaded and its SHA-256 verified; - a revision without a matching release falls back to an exact-revision source build; - `bedrock/.resolved/logos-blockchain-node` and `metadata.json` are produced. Verify the CI consumers: - legacy integration tests; - TF-based integration tests; - Docker-backed `test_fixtures` / `TestContext` tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report the resolved Logos revision and whether the binary was downloaded or built from source. #### ✅ Result After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ▼ one resolved node binary ┌────┼─────┐ ▼ ▼ ▼ TF Cucumber Docker/local ``` Updating the Logos dependency used by LEZ is sufficient to update the Bedrock node used everywhere. If an exact matching release binary exists, it is downloaded and verified. If not, the exact Cargo-resolved revision is built from source. #### 🚫 Out of Scope This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow artifact or cache sharing.
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Aug 26, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for Bedrock node provisioning. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ties all node binaries back to the exact Logos revision resolved by Cargo. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The Cargo-resolved Logos revision is authoritative. Platform-specific node binaries may differ, but they must all correspond to that same exact revision: ```mermaid flowchart TD A["Cargo.toml / Cargo.lock<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>release asset for target platform?"} C -->|Yes| D["Download exact asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["Platform-specific<br/>resolved node"] E --> F F --> G["Linux CI<br/>TF / Cucumber"] F --> H["Linux Docker Bedrock"] F --> I["Host-native TF<br/>when requested"] ``` There is no separately maintained Bedrock Docker tag or node revision that can drift from LEZ's Cargo dependency graph. #### ⚙️ Approach #### Resolve the Cargo-pinned Bedrock node A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all packages sourced from `logos-blockchain/logos-blockchain` resolve to one revision; 4. checks published Logos Blockchain releases for a tag resolving to that exact commit; 5. selects only the exact expected node asset for the requested platform; 6. verifies the published SHA-256 digest; 7. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver verifies the source checkout revision before building. For Docker/CI resolution the canonical output is: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` For explicitly requested host-native resolution: ```text bedrock/.resolved-host/ ├── logos-blockchain-node └── metadata.json ``` The metadata records: - the resolved Logos revision; - the target platform; - whether the binary came from a release or source build; - release information when applicable; - the resulting binary SHA-256. #### Release resolution A published binary is only accepted when all of the following are true: ```mermaid flowchart LR A["Cargo-resolved SHA"] --> B{"Release tag resolves<br/>to exact SHA?"} B -->|No| X["Reject"] B -->|Yes| C{"Exact expected<br/>platform asset exists once?"} C -->|No| X C -->|Yes| D{"Published SHA-256<br/>available and valid?"} D -->|No| X D -->|Yes| E["Download + verify"] ``` The expected asset name is deterministic: ```text logos-blockchain-node-<platform>-<release-tag>.tar.gz ``` Missing, duplicate, or unverifiable assets are not selected. If no suitable release exists, the resolver falls back to building the exact Cargo-resolved revision from source. #### Reuse the resolved node in CI General CI resolves one Linux node and uploads it as an artifact for the jobs that need Bedrock: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock node resolver"] A --> C["integration-tests-prebuild"] B --> D["bedrock-node artifact"] C --> E["nextest archive"] D --> F["Legacy integration-test matrix"] E --> F D --> G["test_fixtures / Docker-backed tests"] D --> H["TF-based tests"] ``` TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build provider. #### Cucumber CI The Cucumber workflow independently resolves the same Cargo-authoritative Linux node: ```mermaid flowchart TD A["ci-image"] --> B["Resolve Cargo-pinned Linux node"] B --> C["Build Cucumber target"] C --> D["@smoke_ci"] D --> E["@auth_transfer_ci"] E --> F["@indexer_state_ci"] F --> G["@multi_sequencer_ci"] ``` Each suite receives: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` The temporary `env -u GITHUB_ACTIONS -u CI` workaround is no longer needed. Cucumber remains separate from nextest. #### Docker-backed Bedrock The legacy independently versioned `0.2.1-lssa` node image is removed. Instead, Docker builds a small runtime image containing the resolved Linux binary: ```mermaid flowchart LR A["Cargo-resolved Logos revision"] A --> B["Resolve Linux node"] B --> C["TF / CI direct execution"] B --> D["Bedrock runtime image"] D --> E["/usr/bin/logos-blockchain-node"] ``` The runtime image uses Debian Trixie so source-built binaries produced in the LEZ CI environment have a compatible runtime. The existing Bedrock configuration, ports, and launch script remain unchanged. #### Local development Docker-backed local Bedrock uses the same Cargo-authoritative resolution path: ```bash just resolve-bedrock-node just run-bedrock ``` `just run-bedrock` resolves the Linux binary and rebuilds the runtime image before starting Compose. The local resolver runs its controlled Linux build environment using the invoking user's UID/GID so generated files and caches remain caller-owned. For explicitly host-native TF usage: ```bash just resolve-host-bedrock-node ``` This writes the native binary to: ```text bedrock/.resolved-host/logos-blockchain-node ``` Docker and host-native binaries may differ by platform, but both correspond to the same Cargo-resolved Logos revision. Docker-backed tests also validate the stored resolver metadata against the current `Cargo.lock`, preventing a stale binary from silently surviving a Logos dependency update. #### 🧪 Resolver Coverage The resolver tests cover: - exact release commit matching; - rejecting releases for another commit; - rejecting unverifiable digests; - rejecting ambiguous duplicate assets; - archive extraction; - rejecting multiple Cargo-resolved Logos revisions; - rejecting source checkouts at the wrong revision; - matching an actual published Logos release through the live GitHub API. The live release test uses the workflow's GitHub token. #### 🧪 How to Test Verify resolver behavior: - the current Cargo graph resolves to one Logos revision; - a matching published release selects only the exact expected platform asset; - the asset digest is verified before extraction; - a revision without a matching release falls back to an exact-revision source build; - resolver metadata records the revision, platform, resolution method, and binary digest. Verify the normal CI consumers: - `test_fixtures`; - legacy integration-test matrix; - TF-based integration tests; - Docker-backed Bedrock tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report: - the Cargo-resolved Logos revision; - the target platform; - whether the binary was downloaded or source-built; - the resulting binary SHA-256. #### ✅ Result After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ┌──────────┴──────────┐ ▼ ▼ Linux node binary Host-native binary │ │ ┌───┴────┐ ▼ ▼ ▼ local native TF CI Docker TF/Cucumber Bedrock ``` Updating LEZ's Logos dependency is sufficient to change the Bedrock node revision used throughout the project. If an exact release asset exists for the requested platform, it is downloaded and verified. If not, that exact Cargo-resolved revision is built from source. #### 🚫 Out of Scope This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow build-artifact sharing.
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Aug 26, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for Bedrock node provisioning. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ties all node binaries back to the exact Logos revision resolved by Cargo. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The Cargo-resolved Logos revision is authoritative. Platform-specific node binaries may differ, but they must all correspond to that same exact revision: ```mermaid flowchart TD A["Cargo.toml / Cargo.lock<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>release asset for target platform?"} C -->|Yes| D["Download exact asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["Platform-specific<br/>resolved node"] E --> F F --> G["Linux CI<br/>TF / Cucumber"] F --> H["Linux Docker Bedrock"] F --> I["Host-native TF<br/>when requested"] ``` There is no separately maintained Bedrock Docker tag or node revision that can drift from LEZ's Cargo dependency graph. #### ⚙️ Approach #### Resolve the Cargo-pinned Bedrock node A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all packages sourced from `logos-blockchain/logos-blockchain` resolve to one revision; 4. checks published Logos Blockchain releases for a tag resolving to that exact commit; 5. selects only the exact expected node asset for the requested platform; 6. verifies the published SHA-256 digest; 7. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver verifies the source checkout revision before building. For Docker/CI resolution the canonical output is: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` For explicitly requested host-native resolution: ```text bedrock/.resolved-host/ ├── logos-blockchain-node └── metadata.json ``` The metadata records: - the resolved Logos revision; - the target platform; - whether the binary came from a release or source build; - release information when applicable; - the resulting binary SHA-256. #### Release resolution A published binary is only accepted when all of the following are true: ```mermaid flowchart LR A["Cargo-resolved SHA"] --> B{"Release tag resolves<br/>to exact SHA?"} B -->|No| X["Reject"] B -->|Yes| C{"Exact expected<br/>platform asset exists once?"} C -->|No| X C -->|Yes| D{"Published SHA-256<br/>available and valid?"} D -->|No| X D -->|Yes| E["Download + verify"] ``` The expected asset name is deterministic: ```text logos-blockchain-node-<platform>-<release-tag>.tar.gz ``` Missing, duplicate, or unverifiable assets are not selected. If no suitable release exists, the resolver falls back to building the exact Cargo-resolved revision from source. #### Reuse the resolved node in CI General CI resolves one Linux node and uploads it as an artifact for the jobs that need Bedrock: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock node resolver"] A --> C["integration-tests-prebuild"] B --> D["bedrock-node artifact"] C --> E["nextest archive"] D --> F["Legacy integration-test matrix"] E --> F D --> G["test_fixtures / Docker-backed tests"] D --> H["TF-based tests"] ``` TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build provider. #### Cucumber CI The Cucumber workflow independently resolves the same Cargo-authoritative Linux node: ```mermaid flowchart TD A["ci-image"] --> B["Resolve Cargo-pinned Linux node"] B --> C["Build Cucumber target"] C --> D["@smoke_ci"] D --> E["@auth_transfer_ci"] E --> F["@indexer_state_ci"] F --> G["@multi_sequencer_ci"] ``` Each suite receives: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` The temporary `env -u GITHUB_ACTIONS -u CI` workaround is no longer needed. Cucumber remains separate from nextest. #### Docker-backed Bedrock The legacy independently versioned `0.2.1-lssa` node image is removed. Instead, Docker builds a small runtime image containing the resolved Linux binary: ```mermaid flowchart LR A["Cargo-resolved Logos revision"] A --> B["Resolve Linux node"] B --> C["TF / CI direct execution"] B --> D["Bedrock runtime image"] D --> E["/usr/bin/logos-blockchain-node"] ``` The runtime image uses Debian Trixie so source-built binaries produced in the LEZ CI environment have a compatible runtime. The existing Bedrock configuration, ports, and launch script remain unchanged. #### Local development Docker-backed local Bedrock uses the same Cargo-authoritative resolution path: ```bash just resolve-bedrock-node just run-bedrock ``` `just run-bedrock` resolves the Linux binary and rebuilds the runtime image before starting Compose. The local resolver runs its controlled Linux build environment using the invoking user's UID/GID so generated files and caches remain caller-owned. For explicitly host-native TF usage: ```bash just resolve-host-bedrock-node ``` This writes the native binary to: ```text bedrock/.resolved-host/logos-blockchain-node ``` Docker and host-native binaries may differ by platform, but both correspond to the same Cargo-resolved Logos revision. Docker-backed tests also validate the stored resolver metadata against the current `Cargo.lock`, preventing a stale binary from silently surviving a Logos dependency update. #### 🧪 Resolver Coverage The resolver tests cover: - exact release commit matching; - rejecting releases for another commit; - rejecting unverifiable digests; - rejecting ambiguous duplicate assets; - archive extraction; - rejecting multiple Cargo-resolved Logos revisions; - rejecting source checkouts at the wrong revision; - matching an actual published Logos release through the live GitHub API. The live release test uses the workflow's GitHub token. #### 🧪 How to Test Verify resolver behavior: - the current Cargo graph resolves to one Logos revision; - a matching published release selects only the exact expected platform asset; - the asset digest is verified before extraction; - a revision without a matching release falls back to an exact-revision source build; - resolver metadata records the revision, platform, resolution method, and binary digest. Verify the normal CI consumers: - `test_fixtures`; - legacy integration-test matrix; - TF-based integration tests; - Docker-backed Bedrock tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report: - the Cargo-resolved Logos revision; - the target platform; - whether the binary was downloaded or source-built; - the resulting binary SHA-256. #### ✅ Result After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ┌──────────┴──────────┐ ▼ ▼ Linux node binary Host-native binary │ │ ┌───┴────┐ ▼ ▼ ▼ local native TF CI Docker TF/Cucumber Bedrock ``` Updating LEZ's Logos dependency is sufficient to change the Bedrock node revision used throughout the project. If an exact release asset exists for the requested platform, it is downloaded and verified. If not, that exact Cargo-resolved revision is built from source. #### 🚫 Out of Scope This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow build-artifact sharing.
15 tasks
Arjentix
approved these changes
Aug 26, 2026
Arjentix
left a comment
Arjentix
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, thanks, looking forward to possible optimizations
4 tasks
# Conflicts: # lez/sequencer/core/src/block_publisher.rs
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Sep 4, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for Bedrock node provisioning. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ties all node binaries back to the exact Logos revision resolved by Cargo. Fixes logos-blockchain#773. Depends on logos-blockchain#779. #### 🔒 Version Contract The Cargo-resolved Logos revision is authoritative. Platform-specific node binaries may differ, but they must all correspond to that same exact revision: ```mermaid flowchart TD A["Cargo.toml / Cargo.lock<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>release asset for target platform?"} C -->|Yes| D["Download exact asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["Platform-specific<br/>resolved node"] E --> F F --> G["Linux CI<br/>TF / Cucumber"] F --> H["Linux Docker Bedrock"] F --> I["Host-native TF<br/>when requested"] ``` There is no separately maintained Bedrock Docker tag or node revision that can drift from LEZ's Cargo dependency graph. #### ⚙️ Approach #### Resolve the Cargo-pinned Bedrock node A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all packages sourced from `logos-blockchain/logos-blockchain` resolve to one revision; 4. checks published Logos Blockchain releases for a tag resolving to that exact commit; 5. selects only the exact expected node asset for the requested platform; 6. verifies the published SHA-256 digest; 7. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver verifies the source checkout revision before building. For Docker/CI resolution the canonical output is: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` For explicitly requested host-native resolution: ```text bedrock/.resolved-host/ ├── logos-blockchain-node └── metadata.json ``` The metadata records: - the resolved Logos revision; - the target platform; - whether the binary came from a release or source build; - release information when applicable; - the resulting binary SHA-256. #### Release resolution A published binary is only accepted when all of the following are true: ```mermaid flowchart LR A["Cargo-resolved SHA"] --> B{"Release tag resolves<br/>to exact SHA?"} B -->|No| X["Reject"] B -->|Yes| C{"Exact expected<br/>platform asset exists once?"} C -->|No| X C -->|Yes| D{"Published SHA-256<br/>available and valid?"} D -->|No| X D -->|Yes| E["Download + verify"] ``` The expected asset name is deterministic: ```text logos-blockchain-node-<platform>-<release-tag>.tar.gz ``` Missing, duplicate, or unverifiable assets are not selected. If no suitable release exists, the resolver falls back to building the exact Cargo-resolved revision from source. #### Reuse the resolved node in CI General CI resolves one Linux node and uploads it as an artifact for the jobs that need Bedrock: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock node resolver"] A --> C["integration-tests-prebuild"] B --> D["bedrock-node artifact"] C --> E["nextest archive"] D --> F["Legacy integration-test matrix"] E --> F D --> G["test_fixtures / Docker-backed tests"] D --> H["TF-based tests"] ``` TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build provider. #### Cucumber CI The Cucumber workflow independently resolves the same Cargo-authoritative Linux node: ```mermaid flowchart TD A["ci-image"] --> B["Resolve Cargo-pinned Linux node"] B --> C["Build Cucumber target"] C --> D["@smoke_ci"] D --> E["@auth_transfer_ci"] E --> F["@indexer_state_ci"] F --> G["@multi_sequencer_ci"] ``` Each suite receives: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` The temporary `env -u GITHUB_ACTIONS -u CI` workaround is no longer needed. Cucumber remains separate from nextest. #### Docker-backed Bedrock The legacy independently versioned `0.2.1-lssa` node image is removed. Instead, Docker builds a small runtime image containing the resolved Linux binary: ```mermaid flowchart LR A["Cargo-resolved Logos revision"] A --> B["Resolve Linux node"] B --> C["TF / CI direct execution"] B --> D["Bedrock runtime image"] D --> E["/usr/bin/logos-blockchain-node"] ``` The runtime image uses Debian Trixie so source-built binaries produced in the LEZ CI environment have a compatible runtime. The existing Bedrock configuration, ports, and launch script remain unchanged. #### Local development Docker-backed local Bedrock uses the same Cargo-authoritative resolution path: ```bash just resolve-bedrock-node just run-bedrock ``` `just run-bedrock` resolves the Linux binary and rebuilds the runtime image before starting Compose. The local resolver runs its controlled Linux build environment using the invoking user's UID/GID so generated files and caches remain caller-owned. For explicitly host-native TF usage: ```bash just resolve-host-bedrock-node ``` This writes the native binary to: ```text bedrock/.resolved-host/logos-blockchain-node ``` Docker and host-native binaries may differ by platform, but both correspond to the same Cargo-resolved Logos revision. Docker-backed tests also validate the stored resolver metadata against the current `Cargo.lock`, preventing a stale binary from silently surviving a Logos dependency update. #### 🧪 Resolver Coverage The resolver tests cover: - exact release commit matching; - rejecting releases for another commit; - rejecting unverifiable digests; - rejecting ambiguous duplicate assets; - archive extraction; - rejecting multiple Cargo-resolved Logos revisions; - rejecting source checkouts at the wrong revision; - matching an actual published Logos release through the live GitHub API. The live release test uses the workflow's GitHub token. #### 🧪 How to Test Verify resolver behavior: - the current Cargo graph resolves to one Logos revision; - a matching published release selects only the exact expected platform asset; - the asset digest is verified before extraction; - a revision without a matching release falls back to an exact-revision source build; - resolver metadata records the revision, platform, resolution method, and binary digest. Verify the normal CI consumers: - `test_fixtures`; - legacy integration-test matrix; - TF-based integration tests; - Docker-backed Bedrock tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report: - the Cargo-resolved Logos revision; - the target platform; - whether the binary was downloaded or source-built; - the resulting binary SHA-256. #### ✅ Result After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ┌──────────┴──────────┐ ▼ ▼ Linux node binary Host-native binary │ │ ┌───┴────┐ ▼ ▼ ▼ local native TF CI Docker TF/Cucumber Bedrock ``` Updating LEZ's Logos dependency is sufficient to change the Bedrock node revision used throughout the project. If an exact release asset exists for the requested platform, it is downloaded and verified. If not, that exact Cargo-resolved revision is built from source. #### 🚫 Out of Scope This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow build-artifact sharing. remove flaky concurrent tf tests single path bedrock binary resolution
hansieodendaal
added a commit
to hansieodendaal/logos-execution-zone
that referenced
this pull request
Sep 4, 2026
…al Docker setup. Resolve logos-blockchain#773 by making the Logos Blockchain revision resolved by LEZ's Cargo dependencies the single source of truth for Bedrock node provisioning. Previously, LEZ could use different Bedrock versions depending on the execution path: - Rust/TF dependencies were pinned to a `logos-blockchain` Git revision; - TF could build a node from that revision; - the legacy Docker setup independently used `0.2.1-lssa`. This PR removes that independent Bedrock version and ties all node binaries back to the exact Logos revision resolved by Cargo. Fixes logos-blockchain#773. Depends on logos-blockchain#779. The Cargo-resolved Logos revision is authoritative. Platform-specific node binaries may differ, but they must all correspond to that same exact revision: ```mermaid flowchart TD A["Cargo.toml / Cargo.lock<br/>Logos dependencies"] --> B["cargo metadata --locked<br/>resolved Logos commit"] B --> C{"Matching published<br/>release asset for target platform?"} C -->|Yes| D["Download exact asset<br/>and verify SHA-256"] C -->|No| E["Build logos-blockchain-node<br/>from exact Cargo checkout"] D --> F["Platform-specific<br/>resolved node"] E --> F F --> G["Linux CI<br/>TF / Cucumber"] F --> H["Linux Docker Bedrock"] F --> I["Host-native TF<br/>when requested"] ``` There is no separately maintained Bedrock Docker tag or node revision that can drift from LEZ's Cargo dependency graph. A shared resolver now: 1. runs `cargo metadata --locked`; 2. determines the exact `logos-blockchain` revision used by LEZ; 3. verifies that all packages sourced from `logos-blockchain/logos-blockchain` resolve to one revision; 4. checks published Logos Blockchain releases for a tag resolving to that exact commit; 5. selects only the exact expected node asset for the requested platform; 6. verifies the published SHA-256 digest; 7. otherwise builds `logos-blockchain-node` from the exact Cargo checkout using: ```bash cargo build --locked --release \ -p logos-blockchain-node \ --features testing ``` The resolver verifies the source checkout revision before building. For Docker/CI resolution the canonical output is: ```text bedrock/.resolved/ ├── logos-blockchain-node └── metadata.json ``` For explicitly requested host-native resolution: ```text bedrock/.resolved-host/ ├── logos-blockchain-node └── metadata.json ``` The metadata records: - the resolved Logos revision; - the target platform; - whether the binary came from a release or source build; - release information when applicable; - the resulting binary SHA-256. A published binary is only accepted when all of the following are true: ```mermaid flowchart LR A["Cargo-resolved SHA"] --> B{"Release tag resolves<br/>to exact SHA?"} B -->|No| X["Reject"] B -->|Yes| C{"Exact expected<br/>platform asset exists once?"} C -->|No| X C -->|Yes| D{"Published SHA-256<br/>available and valid?"} D -->|No| X D -->|Yes| E["Download + verify"] ``` The expected asset name is deterministic: ```text logos-blockchain-node-<platform>-<release-tag>.tar.gz ``` Missing, duplicate, or unverifiable assets are not selected. If no suitable release exists, the resolver falls back to building the exact Cargo-resolved revision from source. General CI resolves one Linux node and uploads it as an artifact for the jobs that need Bedrock: ```mermaid flowchart TD A["ci-image"] --> B["Bedrock node resolver"] A --> C["integration-tests-prebuild"] B --> D["bedrock-node artifact"] C --> E["nextest archive"] D --> F["Legacy integration-test matrix"] E --> F D --> G["test_fixtures / Docker-backed tests"] D --> H["TF-based tests"] ``` TF-based tests receive the resolved binary explicitly through: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` This removes the previous need to recreate Cargo Git state or unset `CI` / `GITHUB_ACTIONS` to force TF onto its source-build provider. The Cucumber workflow independently resolves the same Cargo-authoritative Linux node: ```mermaid flowchart TD A["ci-image"] --> B["Resolve Cargo-pinned Linux node"] B --> C["Build Cucumber target"] C --> D["@smoke_ci"] D --> E["@auth_transfer_ci"] E --> F["@indexer_state_ci"] F --> G["@multi_sequencer_ci"] ``` Each suite receives: ```text LOGOS_BLOCKCHAIN_NODE_BIN=<workspace>/bedrock/.resolved/logos-blockchain-node ``` The temporary `env -u GITHUB_ACTIONS -u CI` workaround is no longer needed. Cucumber remains separate from nextest. The legacy independently versioned `0.2.1-lssa` node image is removed. Instead, Docker builds a small runtime image containing the resolved Linux binary: ```mermaid flowchart LR A["Cargo-resolved Logos revision"] A --> B["Resolve Linux node"] B --> C["TF / CI direct execution"] B --> D["Bedrock runtime image"] D --> E["/usr/bin/logos-blockchain-node"] ``` The runtime image uses Debian Trixie so source-built binaries produced in the LEZ CI environment have a compatible runtime. The existing Bedrock configuration, ports, and launch script remain unchanged. Docker-backed local Bedrock uses the same Cargo-authoritative resolution path: ```bash just resolve-bedrock-node just run-bedrock ``` `just run-bedrock` resolves the Linux binary and rebuilds the runtime image before starting Compose. The local resolver runs its controlled Linux build environment using the invoking user's UID/GID so generated files and caches remain caller-owned. For explicitly host-native TF usage: ```bash just resolve-host-bedrock-node ``` This writes the native binary to: ```text bedrock/.resolved-host/logos-blockchain-node ``` Docker and host-native binaries may differ by platform, but both correspond to the same Cargo-resolved Logos revision. Docker-backed tests also validate the stored resolver metadata against the current `Cargo.lock`, preventing a stale binary from silently surviving a Logos dependency update. The resolver tests cover: - exact release commit matching; - rejecting releases for another commit; - rejecting unverifiable digests; - rejecting ambiguous duplicate assets; - archive extraction; - rejecting multiple Cargo-resolved Logos revisions; - rejecting source checkouts at the wrong revision; - matching an actual published Logos release through the live GitHub API. The live release test uses the workflow's GitHub token. Verify resolver behavior: - the current Cargo graph resolves to one Logos revision; - a matching published release selects only the exact expected platform asset; - the asset digest is verified before extraction; - a revision without a matching release falls back to an exact-revision source build; - resolver metadata records the revision, platform, resolution method, and binary digest. Verify the normal CI consumers: - `test_fixtures`; - legacy integration-test matrix; - TF-based integration tests; - Docker-backed Bedrock tests; - Cucumber suites: - `@smoke_ci` - `@auth_transfer_ci` - `@indexer_state_ci` - `@multi_sequencer_ci` Verify that CI logs report: - the Cargo-resolved Logos revision; - the target platform; - whether the binary was downloaded or source-built; - the resulting binary SHA-256. After this change: ```text LEZ Cargo dependencies │ ▼ exact Logos revision │ ┌──────────┴──────────┐ ▼ ▼ Linux node binary Host-native binary │ │ ┌───┴────┐ ▼ ▼ ▼ local native TF CI Docker TF/Cucumber Bedrock ``` Updating LEZ's Logos dependency is sufficient to change the Bedrock node revision used throughout the project. If an exact release asset exists for the requested platform, it is downloaded and verified. If not, that exact Cargo-resolved revision is built from source. This PR deliberately does not: - change the authoritative Logos dependency revision itself; - combine the General and Cucumber top-level workflows; - route Cucumber through nextest; - implement the separate nextest/Cucumber pre-build sharing optimization discussed in logos-blockchain#779; - change Cucumber scenario concurrency; - introduce cross-workflow build-artifact sharing. remove flaky concurrent tf tests single path bedrock binary resolution
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
2 participants
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.
🎯 Purpose
Add CI coverage for the Cucumber integration tests introduced in #741.
Fixes #774.
⚙️ Approach
dev/mainrun-in-ci-imageexecution modelthiserrordisplay messages from We don't need to specify source in message string #774block_publisher.rsindentation change🧪 How to Test
Open the PR and verify the new
Cucumber integration testsworkflow:@smoke_ci,@auth_transfer_ci,@indexer_state_ci, and@multi_sequencer_ci;🔗 Dependencies
None. #741 is already merged into
dev.🔜 Future Work
#773 will align Bedrock/node binary provisioning so the testing framework can use a deterministic downloadable binary when available and fall back to a source build when required.
Further legacy integration tests can be migrated to Cucumber incrementally.
📋 PR Completion Checklist