Update README.md #51
Closed
Update README.md #51
Conversation
This file contains 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
Changes in PR: - disabled cargo-hfuzz until [the issue](paritytech#5812) is fixed. - enabled condition to skip jobs when no rust files are changed
Bump `zombienet` version to prevent report fails at teardown phase.
cc paritytech/ci_cd#1035 cc paritytech/ci_cd#1023 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: command-bot <> Co-authored-by: Maksym H <1177472+mordamax@users.noreply.github.com> Co-authored-by: gui <gui.thiolliere@gmail.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: ggwpez <ggwpez@users.noreply.github.com>
…ech#5830) Jaeger spans were not usable for debugging, see paritytech#4995, but we pay a price in CPU cost, subsystem-benchmarks show this brings a reduction of about 10-15% in CPU usage per subsystem, so remove it. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
- install frame-omni-bencher from the path - fix bench_features config
This PR removes a workaround which had a reference comment to a rust compiler issue. The issue has been fixed and we should be able to remove that trait bound.
…ech#5838) # Description `substrate-wasm-builder` can be a build dependency for crates which develop FRAME runtimes. I had a tough time seeing errors happening in such crates (e.g. runtimes from the `templates` directory) in my IDE. I use a combination of rust-analyzer + nvim-lsp + nvim-lspconfig + rustacean.vim and all of this stack is not able to correctly parse errors emitted during the `build` phase. As a matter of fact there is also a cargo issue tracking specifically this issue where cargo doesn't propagate the `--message-format` type to the build phase: [here](rust-lang/cargo#14246) initially and then [here](rust-lang/cargo#8283). It feels like a solution for this use case isn't very close, so if it comes to runtimes development (both as an SDK user and developer), enabling wasm builder to emit diagnostics messages friendly to IDEs would be useful for regular workflows where IDEs are used for finding errors instead of manually running `cargo` commands. ## Integration It can be an issue if Substrate/FRAME SDKs users and developers rely on the runtimes' crates build phase output in certain ways. Emitting compilation messages as json will pollute the regular compilation output so people that would manually run `cargo build` or `cargo check` on their crates will have a tougher time extracting the non JSON output. ## Review Notes Rust IDEs based on rust-analyzer rely on cargo check/clippy to extract diagnostic information. The information is generated by passing flags like `--messages-format=json` to the `cargo` commands. The messages are extracted by rust-analyzer and published to LSP clients that will populate UIs accordingly. We need to build against the wasm target by using `message-format=json` too so that IDEs can show the errors for crates that have a build dependency on `substrate-wasm-builder`. --------- Signed-off-by: Iulian Barbu <iulian.barbu@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
Just a tiny config fix Co-authored-by: Bastian Köcher <git@kchr.de>
…tech#5811) # Description Updates the doc comment on the `import_notification_stream` to make its behaviour clearer. Closes [Unexpected behaviour of block `import_notification_stream`](paritytech#5596). ## Integration Doesn't apply. ## Review Notes The old comment docs caused some confusion to myself and some members of my team, on when this notification stream is triggered. This is reflected in the linked [issue](paritytech#5596), and as discussed there, this PR aims to prevent this confusion in future devs looking to make use of this functionality. # Checklist * [x] My PR includes a detailed description as outlined in the "Description" and its two subsections above. * [ ] My PR follows the [labeling requirements]( https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process ) of this project (at minimum one label for `T` required) * External contributors: ask maintainers to put the right label on your PR. * [x] I have made corresponding changes to the documentation (if applicable) * [x] I have added tests that prove my fix is effective or that my feature works (if applicable) You can remove the "Checklist" section once all have been checked. Thank you for your contribution! --------- Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>
This is a refactor and improvement from: paritytech#3881 - `sp_runtime::proving_trie` now exposes a `BasicProvingTrie` for both `base2` and `base16`. - APIs for `base16` are more focused on single value proofs, also aligning their APIs with the `base2` trie - A `ProvingTrie` trait is included which wraps both the `base2` and `base16` trie, and exposes all APIs needed for an end to end scenario. - A `ProofToHashes` trait is exposed which can allow us to write proper benchmarks for the merkle trie. --------- Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
…ytech#5849) This PR backports regular version bumps and prdocs reordering from the `stable2409` release branch to `master` --------- Co-authored-by: Morgan Adamiec <morgan@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
# Description close paritytech#5641 --------- Co-authored-by: Bastian Köcher <git@kchr.de>
…tech#5864) Bumps the known_good_semver group with 1 update: [syn](https://github.com/dtolnay/syn). Updates `syn` from 2.0.77 to 2.0.79 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/syn/releases">syn's releases</a>.</em></p> <blockquote> <h2>2.0.79</h2> <ul> <li>Fix infinite loop on parsing chained ranges (<a href="https://redirect.github.com/dtolnay/syn/issues/1741">#1741</a>)</li> <li>Fix panic in parsing <code>use</code> items containing absolute paths (<a href="https://redirect.github.com/dtolnay/syn/issues/1742">#1742</a>)</li> </ul> <h2>2.0.78</h2> <ul> <li>Fix infinite loop on chained comparison (<a href="https://redirect.github.com/dtolnay/syn/issues/1739">#1739</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dtolnay/syn/commit/732e6e39406538aebe34ed5f5803113a48c28602"><code>732e6e3</code></a> Release 2.0.79</li> <li><a href="https://github.com/dtolnay/syn/commit/af63396422250a1c7c80e6f12da08ce31ea435af"><code>af63396</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1742">#1742</a> from dtolnay/usecrateroot</li> <li><a href="https://github.com/dtolnay/syn/commit/31e863233872eb3f4239a25f42030c369c22d72b"><code>31e8632</code></a> Fix construction of UseGroup containing crate roots</li> <li><a href="https://github.com/dtolnay/syn/commit/037861ac3ca6f91aec7f7c20811535488dafaec4"><code>037861a</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1741">#1741</a> from dtolnay/binoploop</li> <li><a href="https://github.com/dtolnay/syn/commit/8df4dd0fa4c353a2979bd56c34955e9335bb701d"><code>8df4dd0</code></a> Force cursor to advance in parse_expr calls</li> <li><a href="https://github.com/dtolnay/syn/commit/09d020f5a10b3d3e4d54ec03290f773be91b9cac"><code>09d020f</code></a> Release 2.0.78</li> <li><a href="https://github.com/dtolnay/syn/commit/7eaebfbb470fd056ee95ec892fc012ce292e7209"><code>7eaebfb</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/syn/issues/1739">#1739</a> from dtolnay/chainedcomparison</li> <li><a href="https://github.com/dtolnay/syn/commit/b3d2886fc9bbff5eb45995c72beec0463a8cec2a"><code>b3d2886</code></a> Fix infinite loop on chained comparison</li> <li><a href="https://github.com/dtolnay/syn/commit/3f3d0c57ac66b4fa42a3f10209dd1fde29c5ce57"><code>3f3d0c5</code></a> Add regression test for issue 1738</li> <li><a href="https://github.com/dtolnay/syn/commit/346efaec55d7a3865a42fcd1007f45a8a7549052"><code>346efae</code></a> Touch up PR 1737</li> <li>Additional commits viewable in <a href="https://github.com/dtolnay/syn/compare/2.0.77...2.0.79">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Description This PR removes the `CandidateValidationMessage::ValidateFromChainState`, which was previously used by backing, but is no longer relevant since initial async backing implementation paritytech/polkadot#5557. Fixes paritytech#5643 ## Integration This change should not affect downstream projects since `ValidateFromChainState` was already unused. ## Review Notes - Removed all occurrences of `ValidateFromChainState`. - Moved utility functions, previously used in candidate validation tests and malus, exclusively to candidate validation tests as they are no longer used in malus. - Deleted the `polkadot_parachain_candidate_validation_validate_from_chain_state` metric from Prometheus. - Removed `Spawner` from `ReplaceValidationResult` in malus’ interceptors. - `fake_validation_error` was only used for `ValidateFromChainState` handling, while other cases directly used `InvalidCandidate::InvalidOutputs`. It has been replaced with `fake_validation_error`, with a fallback to `InvalidCandidate::InvalidOutputs`. - Updated overseer’s minimal example to replace `ValidateFromChainState` with `ValidateFromExhaustive`.
Normally, the BEEFY protocol only accepts a single MMR Root entry in a commitment's payload. But to be extra careful, when validating equivocation reports, let's check all the MMR roots, if there are more. --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>
Only retry jobs on `runner_system_failure`. Thx!
Quoting @bkchr (from [here](paritytech#5334 (comment))): > That the hardcoded limit is used there again, is IMO not correct. The `max_pov_size` should be controlled by the `HostConfiguration` and not limited by some "random" constant. This PR aims to change the hard limit to a not-so-random constant, allowing more room for maneuvering in the future.
…ains (paritytech#5765) Added `HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>>` foreign locations to local accounts converter to all the parachains. --------- Co-authored-by: command-bot <> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Resolves paritytech#5026 This PR adds support for starting a dev node with manual seal consensus. This can be done by using the `--dev-block-time` argument . For example: ``` polkadot-parachain --chain asset-hub-rococo-dev --dev-block-time 5000 --tmp ```
Bump `zombienet` version, including fixes (`ci`) and the latest version of `pjs` embedded. Thx!
Close paritytech#5589 This PR makes it possible for `rpc_v2::Storage::query_iter_paginated` to be "backpressured" which is achieved by having a channel where the result is sent back and when this channel is "full" we pause the iteration. The chainHead_follow has an internal channel which doesn't represent the actual connection and that is set to a very small number (16). Recall that the JSON-RPC server has a dedicate buffer for each connection by default of 64. #### Notes - Because `archive_storage` also depends on `rpc_v2::Storage::query_iter_paginated` I had to tweak the method to support limits as well. The reason is that archive_storage won't get backpressured properly because it's not an subscription. (it would much easier if it would be a subscription in rpc v2 spec because nothing against querying huge amount storage keys) - `query_iter_paginated` doesn't necessarily return the storage "in order" such as - `query_iter_paginated(vec![("key1", hash), ("key2", value)], ...)` could return them in arbitrary order because it's wrapped in FuturesUnordered but I could change that if we want to process it inorder (it's slower) - there is technically no limit on the number of storage queries in each `chainHead_v1_storage call` rather than the rpc max message limit which 10MB and only allowed to max 16 calls `chainHead_v1_x` concurrently (this should be fine) #### Benchmarks using subxt on localhost - Iterate over 10 accounts on westend-dev -> ~2-3x faster - Fetch 1024 storage values (i.e, not descedant values) -> ~50x faster - Fetch 1024 descendant values -> ~500x faster The reason for this is because as Josep explained in the issue is that one is only allowed query five storage items per call and clients has make lots of calls to drive it forward.. --------- Co-authored-by: command-bot <> Co-authored-by: James Wilson <james@jsdw.me>
- update baseline for pallet_revive - update cmd pipeline name - Fix compilation after renaming some of benchmarks in pallet_revive. [Runtime Dev]. Changed the "instr" benchmark so that it should no longer return to little weight. It is still bogus but at least benchmarking should not work. (by @athei ) --------- Co-authored-by: GitHub Action <action@github.com> Co-authored-by: Alexander Theißen <alex.theissen@me.com> Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com> Co-authored-by: command-bot <>
This PR removes the requirement to set the `LaneId` in the relayer CLI configuration where it was not really necessary. --------- Co-authored-by: command-bot <>
Removing the shell node variant for the polkadot-parachain as discussed here: paritytech#5586 (comment) Resolves paritytech#5898
This PR adds the `stableYYMM-rcX` or `stableYYMM-X-rcX` tags to the docker images, so that they could be published with the new tag naming scheme. Closes: paritytech/release-engineering#224
…ch#5918) Relates to: paritytech#5916 Relates to: polkadot-js/api#5976 --------- Co-authored-by: Javier Viola <javier@parity.io>
…pplicable (paritytech#5789) # Description The EthereumBlobExporter consumes the `dest` parameter when the destination is not `Here`. Subsequent exporters will receive a `None` value for the destination instead of the original destination value, which is incorrect. Closes paritytech#5788 ## Integration Minor fix related to the exporter behaviour. ## Review Notes Verified that tests `exporter_validate_with_invalid_dest_does_not_alter_destination` and `exporter_validate_with_invalid_universal_source_does_not_alter_universal_source` fail without the fix in the exporter. --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>
|
/cmd prdoc --pr 50 --audience "Node Dev" --bump patch |
|
/cmd prdoc --pr 5931 --audience "Node Dev" "Node Operator" --bump patch |
1 similar comment
|
/cmd prdoc --pr 5931 --audience "Node Dev" "Node Operator" --bump patch |
|
/cmd prdoc --pr 5931 --audience "Node Dev" "Node Operator" --bump patch |
|
/cmd prdoc --help |
Command help: |
|
Command "prdoc --pr 5931 --audience "Node Dev" "Node Operator" --bump patch" has started 🚀 See logs here |
|
Command "prdoc --pr 5931 --audience "Node Dev" "Node Operator" --bump patch" has failed ❌! See logs here |
|
/cmd prdoc --pr 5931 --audience 'Node Dev' 'Node Operator' --bump patch |
|
Command "prdoc --pr 5931 --audience 'Node Dev' 'Node Operator' --bump patch" has started 🚀 See logs here |
|
Command "prdoc --pr 5931 --audience 'Node Dev' 'Node Operator' --bump patch" has failed ❌! See logs here |
|
/cmd prdoc --pr 5931 --audience 'Node Dev' 'Node Operator' --bump patch |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
ololo