ci: prototype bulletin-polkadot in integration-test matrix#511
Conversation
Builds the Fellows bulletin-polkadot runtime out-of-tree (default tracks PR polkadot-fellows/runtimes#1170) and runs it on the existing zombienet flow. Configurable via FELLOWS_RUNTIMES_REPO/REF env vars. The Fellows runtime only allows Root or sibling People XCM as Authorizer, so JS/SDK tests that rely on signed authorize_account from TestAccounts are gated behind a new `experimental` matrix flag and skipped for this entry. chain-up + chopsticks compatibility still run, with continue-on-error so prototype breakage does not block PRs. Closes #507
If chain-up or chopsticks fail for the experimental runtime we want a hard signal — silent failures defeat the point of running it in CI.
The full integration-tests matrix excludes experimental entries via the runtime-matrix filter, dropping the per-step `if: !experimental` guards that were sprayed across the workflow. A second job runs only the smoke suite (chain-up + chopsticks) for experimental runtimes.
|
|
||
| chain-spec-builder create \ | ||
| -p 1010 \ | ||
| -c westend \ |
There was a problem hiding this comment.
yeah, per @bkontur comment below: for now westend is ok. we will change it to polkadot-local relay later on...
| "path": "external/fellows-runtimes/system-parachains/bulletin/bulletin-polkadot", | ||
| "uris": [], | ||
| "integration_tests": true, | ||
| "experimental": true, |
There was a problem hiding this comment.
What's the divide between experimental and not?
There was a problem hiding this comment.
What's the divide between experimental and not?
yes, no experimental, point is to add to the runtimes-matrix.json (and do the very minimalistic changes on the way - only where is really needed - justfile, chain-spec script + zombienet, the important one is to run correct bulletin-polkadot-local.toml (for now westend is ok, we will chain with polkadot-local relay later) + scripts/create_bulletin_polkadot_spec.sh which will checkout that branch - this can be hard-coded here or I like external_runtime) and it should run
There was a problem hiding this comment.
yes, no experimental, point is to add to the runtimes-matrix.json (...) and it should run
did that but the CI failed. The Authorizer is Root | EnsureXcm<Equals<PeopleLocation>>. So it accepts either Root or XCM from People. None of them work with local zombie-net.
We can:
- either have a smoke-only job (chain-up + chopsticks)
- or add
#[cfg(feature = "test-accounts")] EnsureSignedBy<TestAccounts, _>to the Authorizer upstream (fellows repo) and build with that feature.
For now having a smoke test looks reasonable to me. What do you think? @bkontur @franciscoaguirre
Also what do we do long term? Can we add second option to fellows? it will make testing way easier...
There was a problem hiding this comment.
- we can request a continuous (auto-renewed) quota for a test account and use that account
There was a problem hiding this comment.
yes, no experimental, point is to add to the runtimes-matrix.json (...) and it should run
did that but the CI failed. The Authorizer is
Root | EnsureXcm<Equals<PeopleLocation>>.So it accepts either Root or XCM from People. None of them work with local zombie-net. We can:1. either have a smoke-only job (chain-up + chopsticks) 2. or add `#[cfg(feature = "test-accounts")] EnsureSignedBy<TestAccounts, _>` to the Authorizer upstream (fellows repo) and build with that feature.For now having a smoke test looks reasonable to me. What do you think? @bkontur @franciscoaguirre Also what do we do long term? Can we add second option to fellows? it will make testing way easier...
exactly, for this, we should be able to use #405 (let me rebase that)
There was a problem hiding this comment.
oh, nice! I was not aware of this PR.
Please, ping me, once you rebase it 🙏🏻
Per review, drop the experimental flag + dedicated job. The runtime ships through the same matrix as bulletin-westend/paseo so the full suite runs against it.
- runtimes-matrix.json: nest `path` under `external_runtime`, add the production `uris` so try-runtime migration checks pick it up. - create_bulletin_polkadot_spec.sh: only run chain-spec-builder; take the WASM via `WASM_PATH`. - justfile: new `build-external-runtime` recipe handles clone+build, prints the WASM path. - integration-test.yml: resolve Fellows commit sha, cache the WASM build on that key, build before `Start services`.
The check-runtime-migration workflow used `cargo build -p $PACKAGE` on the local workspace, which doesn't work for runtimes that live in an out-of-tree repo (bulletin-polkadot lives in the fellows runtimes fork). When the matrix entry has `external_runtime`, resolve the upstream sha, cache the build under `target/external-runtimes/<name>-try-runtime`, and build via just; then point try-runtime at the resulting WASM. Local-workspace runtimes still go through the original cargo path. The just recipe now takes optional features and routes feature variants to separate checkout directories so caches don't collide with the no-features build used by integration-tests.
…n-polkadot-ci # Conflicts: # examples/justfile
The external runtime ref now targets x3c41a/runtimes@ndk/port-pr405, which bumps the bulletin pallet deps past 0.2.0-draft and wires #405's `EnsureAllowedAuthorizers` + `allowed_authorizers` genesis seed into the runtime. This is what unblocks the local-zombienet authorize-and-store tests for bulletin-polkadot, which were failing with BadSigner because the previous Authorizer was Root | XCM-from-People only. Move the matrix back to bkontur/runtimes once #405 is upstreamed there.
…n-polkadot-ci # Conflicts: # .github/workflows/integration-test.yml
3 participants
Closes #507
Adds bulletin-polkadot to the integration test matrix. The runtime is built from polkadot-fellows/runtimes#1170 (override the source via
FELLOWS_RUNTIMES_REPO/FELLOWS_RUNTIMES_REF). Runs through the same job as bulletin-westend / paseo.Test plan