perf(ci): build common artifacts once, run the two test suites in parallel#130
Merged
Conversation
…allel
The integration-tests and sc-integration-tests jobs each rebuilt the runtime
and provider before running their demos. Factor the shared compilation into a
single 'build' job and have both consume its artifact:
build Compile the COMMON stuff once: every runtime wasm
(looping the runtimes matrix file, for zombienet's
chain_spec_command) and the provider node, uploaded as
one 'build' artifact.
integration-tests Download the artifact, spawn its own chain + inmemory
and disk providers, run the L0 / fs / s3 / papi demos.
fs/s3 still 'cargo run' their examples (incremental off
the restored build cache).
sc-integration-tests Download the artifact, install solc/resolc + build the
example contracts, spawn its own chain + inmemory
provider, run the smart-contract demos.
The two test jobs run in parallel and skip the runtime/provider build. Demos
stay sequential within each job (drain-tx-pool-then preserved).
The build-once artifact uploads both target/release/storage-provider-node and the runtime wasm under target/release/wbuild, so upload-artifact roots the archive at their least common ancestor (target/release) and strips that prefix. The test jobs downloaded into '.', landing the binary at ./storage-provider-node, so 'chmod +x target/release/storage-provider-node' failed with 'No such file or directory'. Download into target/release so the stripped prefix is restored where chmod, the chain_spec_command scripts, and the demos expect it. Also upload only the final *.compact.compressed.wasm per runtime instead of the entire wbuild Cargo scratch tree, cutting the artifact from ~927 MiB / 3453 files to a handful of files and making the download/extract near-instant. LCA stays target/release, so the download fix covers both.
The header comment claimed the build artifact carries the fs/s3 example binaries and the Solidity contracts and that the test jobs compile nothing. Neither is true: the artifact holds only the provider binary and the compressed runtime wasm, the fs/s3 demos still 'cargo run' their example crates, and the sc job still installs solc/resolc and builds contracts. Rewrite both comments to describe what actually happens and note the test jobs lean on the shared Rust cache.
submitTx now resolves at in-block inclusion rather than finalization, so a
demo that reads state right after a write was racing the ~6-block finality
lag: storage reads default to the finalized head, so the just-included write
wasn't visible yet (e.g. full-flow's fetchChallengeProof failing with
"No challenges at deadline").
Point every post-write read in the PAPI demos at the best (non-finalized)
block via a single shared READ_OPTS = { at: "best" } exported from common.js
-- one switch for the whole suite (flip to "finalized" there to revert).
Covers the CI demos (full-flow/api, s3-lifecycle, drive-lifecycle, sc-flow,
sc-coverage, sc-token-gated, common helpers) plus the non-CI demos
(checkpoint-rewards, checkpoint-missed, bucket-membership, provider-discovery)
for consistency.
full-flow's verification used api.event...ChallengeDefended.watch(), which only observes FINALIZED blocks. With in-block tx submission the two defenses land in best (not-yet-finalized) blocks, so a count taken right after (even behind a 3s sleep) read 0 -> "Expected 2 ChallengeDefended events, got 0". The respond_to_challenge dispatch emits ChallengeDefended in the same block the tx lands in, so extract it from each response's in-block events via requireOneEvent instead. Deterministic and race-free; drops the sleep.
…engeNotFound
A challenge's id embeds the block height it was created at, and
respond_to_challenge references that exact id. With in-block submission the
creating tx sits in a best block that — even with a single collator — can be
reorged before it's relay-backed/finalized, rolling the challenge out from
under the response (seen as 'respond_to_challenge dispatch failed:
ChallengeNotFound' when the response lands a few blocks later, as with the
slower disk provider).
Add submitTxFinalized (waits for a finalized block) and use it only for the
challenge creators: challengeOffchain + challengeCheckpoint (api.js), and the
challengeCheckpoint precompile call in sc-coverage via a new callContract
{ finalized: true } opt. Everything else stays in-block. Two extra finality
waits per affected demo, still far under the 30-min cap.
Smaller requested duration shortens the 'wait for agreement expiry' step (expires_at = accept_block + duration). 15 stays >= the provider's min_duration (10), and max_payment scales automatically off duration.
5 tasks
ui-e2e.yml filtered at the WORKFLOW level (on.*.paths), so on PRs that touch none of those paths the whole workflow was skipped and the required status check 'UI E2E Tests (chain + provider + UIs)' never reported — leaving such PRs permanently BLOCKED in branch protection (e.g. CI-only / PAPI-demo changes). Adopt the same shape ui-checks.yml already uses: drop the top-level paths filter, detect relevant changes in a 'changes' job, gate the heavy e2e job (now 'UI E2E run') on it, and add an always-running aggregate job that carries the required context name and is green on skip, red on real failure/cancellation.
Condense the comment blocks across the integration-tests/ui-e2e workflows and the PAPI demos (READ_OPTS, submitTx/submitTxFinalized, challenge-finalize and event-read notes) to one or two lines each, keeping the 'why' and dropping the restated mechanics. Comments only; no behaviour change.
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
1 participant
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.
No description provided.