There have been some subtle changes to the release process since this document was last updated. This PR updates the RELEASE.md to reflect these changes.
* Remove transaction-pool `test-helpers` feature
`test-helpers` feature is a bad idea in general, because once the feature is enabled somewhere in
the workspace, it is enabled anywhere. While removing the feature, the tests were also rewritten to
get rid off other "only test" related code.
Contributes towards: https://github.com/paritytech/substrate/issues/9727
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Fix benches
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
Closes#3971
Read the linked issue.
Apart from that, this addresses the concern raised in this [comment] by
just adding a test. I couldn't find a clean way to reconcile a block
number delay with a PVF voting TTL, so I just resorted to rely on the
test. Should be fine for now.
[comment]: https://github.com/paritytech/polkadot/pull/4457#discussion_r770517562
* paras: add governance control dispatchables
Adds a couple of functions for governance control for the paras module
in the anticipation of PVF pre-checking enabling.
Specifically, this commit adds a function for pre-registering a PVF that
governance trusts enough. This function will come in handy in case there
is a parachain that does not follow the GoAhead signal. That is, does
not include https://github.com/paritytech/cumulus/pull/517.
This may be not an exhaustive list of the functions that may come in
handy. Any suggestions to add more are welcome.
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_paras.rs
* cargo run --quiet --release --features runtime-benchmarks -- benchmark --chain=rococo-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/rococo/src/weights/runtime_parachains_paras.rs
Co-authored-by: Parity Bot <admin@parity.io>
* add custom profiles and specify MSVR as 1.57
* fix host-perf-check command
* use testnet profile for CI images
* do not do lto for testnet profile
* fix artifact path
* test with testnet profile to reuse build artifacts
* Revert "fix host-perf-check command"
This reverts commit f1d15492204b8251685a97636cbb5a5f394f21da.
* bump zombienet version
Co-authored-by: Javier Viola <javier@parity.io>
Closes#4248
Impose additional constraint on configuration consistency:
`validation_upgrade_delay` should not be less than or equal to 1.
See the original issue for more details.
Setting zero as weight may be a source of problems.
The problem is, a rogue validator can shove a lot of duplicated votes
and thus fill a block with work that may well exceed the weight limit.
This commit refactors the consistency checks. Instead of each individual
setter performs its checks locally, we delegate those checks to the
already existing function `check_consistency`. This removes duplication
and simplifies the logic.
A motivating example of this one is the next PR in the stack that will
introduce a check for a field, which validity depends on the validity of
other two fields. Without this refactoring we will have to place a check
not only to the field in question, but also to the other two fields so
that if they are changed they do not violate consistency criteria. It's
easy to imagine how this can go unwieldy with the number of checks.
This also adds a test that verifies that the default chain spec host
configuration is consistent.
* zombinet: fixed adder-collator image for the smoke test
* update COL_IMAGE
* bump zombienet version
* try a different version
Co-authored-by: Javier Viola <javier@parity.io>
Make check-dependent-* jobs only be executed in PRs instead of both PRs and
master.
Reason 1: The companion is not merged at the same time as the parent PR
([1](https://github.com/paritytech/parity-processbot/issues/347#issuecomment-994729950)),
therefore the pipeline will fail on master since the companion PR is not yet
merged in the other repository. This scenario is demonstrated by the pipeline
of
https://github.com/paritytech/substrate/commit/82cc3746450ae9722a249f4ddf83b8de59ba6e0d.
Reason 2: The job can still fail on master due to a new commit on the companion
PR's repository which was merged after `bot merge` happened, as demonstrated by
the following scheme:
1. Parent PR is merged
2. Companion PR is updated and set to merge in the future
3. In the meantime a new commit is merged into the companion PR repository's
master branch
4. The `check-dependent-*` job runs on master but, due to the new commit, it
fails for unrelated reasons
While "Reason 2" can be used as an argument against this PR, in that it would
be useful to know if the integration is failing on master, "Reason 1" should be
taken care of due to this inherent flaw of the current companion build system
design.
Make check-dependent-* jobs only be executed in PRs instead of both PRs and master.
Reason 1: The companion is not merged at the same time as the parent PR
([1](https://github.com/paritytech/parity-processbot/issues/347#issuecomment-994729950)), therefore
the pipeline will fail on master since the companion PR is not yet merged in the other repository.
This scenario is demonstrated by the pipeline of https://github.com/paritytech/substrate/commit/3d8ce67383bfc588d67772db5739fc55936908d2.
Reason 2: The job can still fail on master due to a new commit on the companion PR's repository which was merged after `bot merge` happened, as demonstrated by the following scheme:
1. Parent PR is merged
2. Companion PR is updated and set to merge in the future
3. In the meantime a new commit is merged into the companion PR repository's master branch
4. The `check-dependent-*` job runs on master but, due to the new commit, it fails for unrelated reasons
While "Reason 2" can be used as an argument against this PR, in that it would be useful to know if the integration is failing on master, "Reason 1" should be taken care of due to this inherent flaw of the current companion build system design.
* Improve SS58 related errors
This improves the SS58 error, especially when it comes to parsing public keys with unknown SS58
address formats.
* Make CI happy
* More fixes
* More
* 🤦
* fml...
* sketch downward messages
* bring in attempt to mock mqc-head from moonbeam
* just patch individual crates
* fing comma
* add some logs
* Holy shit, we actually imported a block!
* Actually mock the message queue chain
* use relay parent number for `sent_at`
* finish moving MQC to primitives
* more complete mock and better config type
* change name
* fix export
* better map types
* fix dependencies after rebase
* try-rejigging branches because this is an override
* try to re-jig for hrmp mcqs
* fix branches
* actually fix branches better
* even better
* Removestray log lines
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* Nicer handling of default `ParachainSystem` name
* better docs
* Default MockXcm for people who only who don't care to mock xcm.
* cargo fmt
* trailing commas
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* use the variable for hrmp to
* fix deref
* deduplicate MessageQueueChain
* better docs for MessageQueueChain
* Use `Vec<u8>` instead of `&'static [u8]`
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* cargo fmt
* associated changes for using Vec<u8>
* Unused import
* Fix compilation
Co-authored-by: Joshy Orndorff <admin@joshyorndorff.com>
Co-authored-by: Joshy Orndorff <JoshOrndorff@users.noreply.github.com>
* state-update4 branch
* new ref
* Update to latest.
* update deps
* switch to host state version
* update
* fmt
* up
* remove trie patch
* remove patch
* fmt
* update
* set state_versions in runtimes
* state version from storage
* state version from storage
* seedling compat
* restore lock
* update lockfile for substrate
* update lockfile for polkadot
Co-authored-by: parity-processbot <>
dependabot[bot]