Gate releases against previewnet and paseo-next-v2 - #78
Open
mordamax wants to merge 25 commits into
Open
Conversation
Runs the Polkadot proof-of-personhood chain tests against a fork of each network these runtimes are deployed to, using the wasm build-runtimes already produced in the same run. Does not block publishing: the publish jobs do not depend on it, so a failure reds the run without holding up artifacts.
preview-net-v1 is the only private repo the gate touches here — the runtimes come from the build artifact, not from paritytech/individuality — so the token is scoped to just the engine and named for it.
mordamax
marked this pull request as ready for review
August 28, 2026 12:10
mordamax
marked this pull request as draft
August 28, 2026 12:11
Reuses the wasm build-e2e-runtime-wasm already produces on each PR, so there is no second build. Also stages the compressed variants, which wbuild already emits: an on-chain upgrade takes the compressed blob and the plain one can exceed the block limit on set_code.
build-e2e-runtime-wasm already carries one and chain-tests needs it, so a draft skips both. The explicit condition also failed on workflow_dispatch, where github.event.pull_request is absent.
mordamax
marked this pull request as ready for review
August 28, 2026 13:29
A build from source carries the committed spec_version, which is what the chain already runs, so the upgrade was a no-op and the gate tested nothing about the PR's code. Multiplying by 100 keeps the committed digits visible in the result.
The format is M_XXX_YYY with YYY always 000 on main and reserved for nightlies, so +1 is strictly greater than main and stays clear of every future release. Multiplying by 100 would shoot past them entirely.
Contributor
Author
|
Rebased the spec_version approach onto #74's scheme: the build now stamps Happy to close #66 in favour of #74 — this integration doesn't depend on it. |
rust-cache restored target/ and cargo reused the cached wasm despite the spec_version edit — the build finished in 5 minutes and the artifact still carried 2000039, so the gate upgraded nothing and reported success. Cleaning only these two packages keeps every dependency cached.
The build was already recompiling from the stamped source — both runs' artifacts carried spec_version 2000040. The stale wasm was a misdiagnosis; the gate was ignoring the artifact.
paseo-next-v2 runs the v0.11 line; applying a runtime built from main there is a migration nobody intends to perform. Add it back once it is on the same line.
A network that cannot take the runtime is the signal, not noise — it is what a missing or broken migration looks like.
andrzejSulkowski
self-requested a review
August 31, 2026 09:09
kianenigma
added a commit
that referenced
this pull request
Aug 31, 2026
See [RELEASE.md](https://github.com/paritytech/individuality-community/pull/74/changes#diff-2b1b69303b927a484e02c7fad9fc87d0d3ff0dc22ae1da0ecd0dc935d922a23c) The plan after this would be to release with runtime spec versions `3_000_000` and version `0.3.0`. * #78 can integrate to the new flow once it is merged. * #66 can be closed if @mordamax approves this.
mordamax
added
the
C0-non-breaking
Contributor
Author
|
@paritytech/pop i made a release/nightly publish depend on the gate - so if chain-tests fails - the release doesn't get cut. Before it would publish anyway and just leave a red badge but that means a failed release or nightly can now go unnoticed - nothing gets published and nobody is told so i'd suggest we post a notification to your team room when it fails, so it's visible and someone picks it up (i can wire it up with our Earvin matrix bot - just tell me the room ID where you want to get notification and preferred format - otherwise i'll improvise)) p.s. auto issues i'd avoid - easy to ignore and they pile up |
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.
Runs the Polkadot proof-of-personhood chain tests against every release cut here, on a fork of each network these runtimes are actually deployed to.
Today a runtime is cut and handed to SRE with nothing having tried it against a real network first. This closes that: by the time a release leaves this repo it carries a verdict.
What it does
Adds one
chain-testsjob to Release and Nightly Release. It calls the gate in paritytech/polkadot-pop-e2e, which forks previewnet and paseo-next-v2, upgrades each to these runtimes, and runs the suite — chain health, ring builder, identity backend, allowances, PoP-gated contract calls, alias claims.It reuses the wasm
build-runtimesalready produced rather than rebuilding. A called workflow's jobs run inside this run, so the gate downloads the artifacts directly — no token for that part, no cross-repo API, no second srtool build.Each network is diffed against its own deployed pin, so the run reports what would actually change:
It does not block publishing
The publish jobs don't depend on it. A gate failure reds the run and tells you what broke without holding up artifacts. Add
chain-teststo publish'sneedsto make it blocking — worth doing once the signal has proven itself, not before.The one secret it needs
GH_PAT_PPNV1—contents: readonparitytech/preview-net-v1. Set.That is the private engine that spawns the fork, and it is the only private repo involved. The runtimes come from the artifact built above rather than being fetched from
paritytech/individuality, and every other pin — bulletin, web3-storage, release-automation, paseo-network/runtimes, kubo — is public and needs no token.If the token is ever wrong, the gate fails fast and names the repo it could not read rather than dying on an unexplained 403 later.
spec_version
A build straight from source carries the committed
spec_version, which is what the chain already runs — so the first real run reported2000039 -> 2000039 (already-installed), upgraded nothing and tested none of the PR's code while going green.The build now stamps
+1in the workspace only, landing in the band RELEASE.md reserves (M_XXX_YYY,YYYalways000on main and belonging to nightlies). Nothing is committed back, so theSpec versioncheck — which reads the committed source — is unaffected, and the value stays clear of every future release.Reads whatever is committed, so it follows #74's move to
3_000_000with no change here.Cost
Two forks per release, roughly 25 minutes each on
parity-large, in parallel with publishing. Nightly and tagged releases only — nothing on PRs.Gating a PR's runtime before merge is possible with the same machinery (the gate takes a built wasm, not just a published release) but means an srtool build per PR, so it's a separate conversation.