Testing without docker-in-dockler #57
Draft
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
…allet pallet_balances --clean'
…allet pallet_balances'
…t pallet_balances'
…=westend --target_dir=polkadot --pallet=pallet_balances
…=westend --target_dir=polkadot --pallet=pallet_balances --machine=y
Co-authored-by: GitHub Action <[email protected]> Co-authored-by: Cyrill Leutwiler <[email protected]>
[`LocalTransactionPool` trait](https://github.com/paritytech/polkadot-sdk/blob/d5b96e9e7f24adc1799f8e426c5cb69b4f2dbf8a/substrate/client/transaction-pool/api/src/lib.rs#L408-L426) is now implemented for `ForkAwareTransactionPool`. Closes paritytech#5493
) I noticed that hardware benchmarks are being run even though we pass the --no-hardware-benchmarks cli flag. After some debugging, the cause is an incorrect usage of the `then_some` method. From [std docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some): > Arguments passed to then_some are eagerly evaluated; if you are passing the result of a function call, it is recommended to use [then](https://doc.rust-lang.org/std/primitive.bool.html#method.then), which is lazily evaluated. ```rust let mut a = 0; let mut function_with_side_effects = || { a += 1; }; true.then_some(function_with_side_effects()); false.then_some(function_with_side_effects()); // `a` is incremented twice because the value passed to `then_some` is // evaluated eagerly. assert_eq!(a, 2); ``` This PR fixes all the similar usages of the `then_some` method across the codebase. polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
…paritytech#6080) A follow-up to paritytech#5599. Assets in a pool with the native one are returned from `query_acceptable_payment_assets`. Now those assets can be used in `query_weight_to_asset_fee` to get the correct amount that needs to be paid. --------- Co-authored-by: command-bot <>
Add pallet-revive to Westend runtime, and configure the runtime to accept Ethereum signed transaction
provides low-level documentation on how the omni-node is meant to work. This is meant to act as reusable material for other teams (e.g. Papermoon and W3F) to use and integrate into the high level Polkadot documentation. Broadly speaking, for omni-node to have great rust-docs, we need to focus on the following crates, all of which got a bit of love in this PR: 1. `sp-genesis-builder` 2. `polkadot-omni-node` 3. `polkadot-omni-node-lib` 4. `frame-omni-bencher` On top of this, we have now: * `polkadot_sdk_docs::guides` contains two new steps demonstrating the most basic version of composing your pallet, putting it into a runtime, and putting that runtime into omni-node * `polkadot_sdk_docs::reference_docs::omni_node` to explain in more detail how omni-node differs from the old-school node. * `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to finally have a minimal reference about weights and benchmarking. * It provides tests for some of the steps in paritytech#5568 closes paritytech#5568 closes paritytech#4781 Next steps - [x] Ensure the README of the parachain template is up-to-date. @iulianbarbu - [ ] Readme for `polkadot-omni-node` and similar is updated. For now, use `cargo-readme` and copy over the rust-docs. To build the branch locally and run this: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally --------- Co-authored-by: Iulian Barbu <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: Michal Kucharczyk <[email protected]>
Closes paritytech#6161 Westend BridgeHub freezes for a while at block 3 and if we try to init the bridge and fund the accounts during that time, it fails. So we wait untill all the parachains produced at least 10 blocks, in order to make sure that they work reliably.
Fix hardcoded gas limits in tests --------- Co-authored-by: GitHub Action <[email protected]>
…hains (paritytech#6212) Added missing API methods to Rococo and Westend parachains. Preparatory work for making chopstick tests run smoothly. Follow-up of [PR#6039](paritytech#6039)
…ritytech#6216) # Description Snowbridge PNA has been audited. A number of issues where raised due to not understanding the fee model for Polkadot Native Assets(PNA) implementation. This PR addresses this by adding more comments and better naming of private functions. ## Integration None, documentation and private method name changes.
The approval-voting-parallel introduced with paritytech#4849 has been tested on `versi` and approximately 3 weeks on parity's existing kusama nodes paritytech/devops#3583, things worked as expected, so enable it by default on all kusama nodes in the next release. The next step will be enabling by default on polkadot if no issue arrises while running on kusama. --------- Signed-off-by: Alexandru Gheorghe <[email protected]>
Fix paritytech#5185 also implement handling of attr in expansion in construct-runtime --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: GitHub Action <[email protected]> Co-authored-by: Cyrill Leutwiler <[email protected]>
[`LocalTransactionPool` trait](https://github.com/paritytech/polkadot-sdk/blob/d5b96e9e7f24adc1799f8e426c5cb69b4f2dbf8a/substrate/client/transaction-pool/api/src/lib.rs#L408-L426) is now implemented for `ForkAwareTransactionPool`. Closes paritytech#5493
) I noticed that hardware benchmarks are being run even though we pass the --no-hardware-benchmarks cli flag. After some debugging, the cause is an incorrect usage of the `then_some` method. From [std docs](https://doc.rust-lang.org/std/primitive.bool.html#method.then_some): > Arguments passed to then_some are eagerly evaluated; if you are passing the result of a function call, it is recommended to use [then](https://doc.rust-lang.org/std/primitive.bool.html#method.then), which is lazily evaluated. ```rust let mut a = 0; let mut function_with_side_effects = || { a += 1; }; true.then_some(function_with_side_effects()); false.then_some(function_with_side_effects()); // `a` is incremented twice because the value passed to `then_some` is // evaluated eagerly. assert_eq!(a, 2); ``` This PR fixes all the similar usages of the `then_some` method across the codebase. polkadot address: 138eUqXvUYT3o4GdbnWQfGRzM8yDWh5Q2eFrFULL7RAXzdWD --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
…paritytech#6080) A follow-up to paritytech#5599. Assets in a pool with the native one are returned from `query_acceptable_payment_assets`. Now those assets can be used in `query_weight_to_asset_fee` to get the correct amount that needs to be paid. --------- Co-authored-by: command-bot <>
Add pallet-revive to Westend runtime, and configure the runtime to accept Ethereum signed transaction
provides low-level documentation on how the omni-node is meant to work. This is meant to act as reusable material for other teams (e.g. Papermoon and W3F) to use and integrate into the high level Polkadot documentation. Broadly speaking, for omni-node to have great rust-docs, we need to focus on the following crates, all of which got a bit of love in this PR: 1. `sp-genesis-builder` 2. `polkadot-omni-node` 3. `polkadot-omni-node-lib` 4. `frame-omni-bencher` On top of this, we have now: * `polkadot_sdk_docs::guides` contains two new steps demonstrating the most basic version of composing your pallet, putting it into a runtime, and putting that runtime into omni-node * `polkadot_sdk_docs::reference_docs::omni_node` to explain in more detail how omni-node differs from the old-school node. * `polkadot_sdk_docs::reference_docs::frame_weight_benchmarking` to finally have a minimal reference about weights and benchmarking. * It provides tests for some of the steps in paritytech#5568 closes paritytech#5568 closes paritytech#4781 Next steps - [x] Ensure the README of the parachain template is up-to-date. @iulianbarbu - [ ] Readme for `polkadot-omni-node` and similar is updated. For now, use `cargo-readme` and copy over the rust-docs. To build the branch locally and run this: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/meta_contributing/index.html#how-to-develop-locally --------- Co-authored-by: Iulian Barbu <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: Michal Kucharczyk <[email protected]>
Closes paritytech#6161 Westend BridgeHub freezes for a while at block 3 and if we try to init the bridge and fund the accounts during that time, it fails. So we wait untill all the parachains produced at least 10 blocks, in order to make sure that they work reliably.
Fix hardcoded gas limits in tests --------- Co-authored-by: GitHub Action <[email protected]>
…hains (paritytech#6212) Added missing API methods to Rococo and Westend parachains. Preparatory work for making chopstick tests run smoothly. Follow-up of [PR#6039](paritytech#6039)
…ritytech#6216) # Description Snowbridge PNA has been audited. A number of issues where raised due to not understanding the fee model for Polkadot Native Assets(PNA) implementation. This PR addresses this by adding more comments and better naming of private functions. ## Integration None, documentation and private method name changes.
The approval-voting-parallel introduced with paritytech#4849 has been tested on `versi` and approximately 3 weeks on parity's existing kusama nodes paritytech/devops#3583, things worked as expected, so enable it by default on all kusama nodes in the next release. The next step will be enabling by default on polkadot if no issue arrises while running on kusama. --------- Signed-off-by: Alexandru Gheorghe <[email protected]>
Fix paritytech#5185 also implement handling of attr in expansion in construct-runtime --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
Flaky tests reported in paritytech#6062 paritytech#6063 (already fixed) Thx!
Just fix a tiny typo
The max size of a message should not depend on the weight left in a given execution context. Instead the max message size depends on the service weights configured for the pallet. A message that may does not fit into `on_idle` is not automatically overweight, because it may can be executed successfully in `on_initialize` or in another block in `on_idle` when there is more weight left. --------- Co-authored-by: GitHub Action <[email protected]>
|
/cmd bench --runtime westend --pallet pallet_balances --clean |
|
Command "bench --runtime westend --pallet pallet_balances --clean" has started 🚀 See logs here |
…t pallet_balances --clean'
|
Command "bench --runtime westend --pallet pallet_balances --clean" has finished ✅ See logs here Subweight results:
Command output:✅ Successful benchmarks of runtimes/pallets: |
mordamax
force-pushed
the
master
branch
2 times, most recently
from
d7681f0
to
17eee37
Compare
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.
✄ -----------------------------------------------------------------------------
Thank you for your Pull Request! 🙏 Please make sure it follows the contribution guidelines outlined in this
document and fill out the
sections below. Once you're ready to submit your PR for review, please delete this section and leave only the text under
the "Description" heading.
Description
A concise description of what your PR is doing, and what potential issue it is solving. Use Github semantic
linking
to link the PR to an issue that must be closed once this is merged.
Integration
In depth notes about how this PR should be integrated by downstream projects. This part is mandatory, and should be
reviewed by reviewers, if the PR does NOT have the
R0-Silentlabel. In case of aR0-Silent, it can be ignored.Review Notes
In depth notes about the implementation details of your PR. This should be the main guide for reviewers to
understand your approach and effectively review it. If too long, use
<details>.Imagine that someone who is depending on the old code wants to integrate your new code and the only information that
they get is this section. It helps to include example usage and default value here, with a
diffcode-block to showpossibly integration.
Include your leftover TODOs, if any, here.
Checklist
Trequired)You can remove the "Checklist" section once all have been checked. Thank you for your contribution!
✄ -----------------------------------------------------------------------------