- Jan 27, 2025
-
-
christopher k authored
# Description This PR adds development chain specs for the minimal and parachain templates. [#6334](https://github.com/paritytech/polkadot-sdk/issues/6334) ## Integration This PR adds development chain specs for the minimal and para chain template runtimes, ensuring synchronization with runtime code. It updates zombienet-omni-node.toml, zombinet.toml files to include valid chain spec paths, simplifying configuration for zombienet in the parachain and minimal template. ## Review Notes 1. Overview of Changes: - Added development chain specs for use in the minimal and parachain template. - Updated zombienet-omni-node.toml and zombinet.toml files in the minimal and parachain templates to include paths to the new dev chain specs. 2. Integration Guidance: **NB: Follow the templates' READMEs from the polkadot-SDK master branch. Please build the binaries and runtimes based on the polkadot-SDK master branch.*...
-
- Dec 10, 2024
-
-
Iulian Barbu authored
# Description This PR changes a few things: * `--dev` flag will not conflict with `--chain` anymore, but if `--chain` is not given will set `--chain=dev`. * `--dev-block-time` is optional and it defaults to 3000ms if not set after setting `--dev`. * to start OmniNode with manual seal it is enough to pass just `--dev`. * `--dev-block-time` can still be used to start a node with manual seal, but it will not set it up as `--dev` does (it will not set a bunch of flags which are enabled by default when `--dev` is set: e.g. `--tmp`, `--alice` and `--force-authoring`. Closes: #6537 ## Integration Relevant for node/runtime developers that use OmniNode lib, including `polkadot-omni-node` binary, although the recommended way for runtime development is to use `chopsticks`. ## Review Notes * Decided to focus only on OmniNode & templates docs in relation to it, and leave the `parachain-template-node` as is (meaning `--dev` isn't usable and testing a runtime with the `parachain-template-node` still needs a relay chain here). I am doing this because I think we want either way to phase out `parachain-template-node` and adding manual seal support for it is wasted effort. We might add support though if the demand is for `parachain-template-node`. * Decided to not infer the block time based on AURA config yet because there is still the option of setting a specific block time by using `--dev-block-time`. Also, would want first to align & merge on runtime metadata checks we added in Omni Node here: https://github.com/paritytech/polkadot-sdk/pull/6450 before starting to infer AURA config slot duration via the same way. - [x] update the docs to mention `--dev` now. - [x] mention about chopsticks in the context of runtime development --------- Signed-off-by:
Iulian Barbu <iulian.barbu@parity.io> Co-authored-by:
Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
-
- Nov 04, 2024
-
-
Iulian Barbu authored
# Description Closes #5940 ## Integration Node devs that rely on templates' nodes binaries for minimal or parachain would need to follow the updated templates' README.mds again to find how to build the nodes' binaries. ## Review Notes Conditional compilation of virtual workspaces would compile the `members` list as if we passed `--workspace` flag to `cargo build` , except when adding a `default-members` list which will be used for any cargo command executed in the virtual workspace root. To build the full members list needs passing `--workspace` flag. Other options investigated: - feature guard the `node` crate by defining a feature in the `node` crate, but it feels too complex since all code needs to be feature guarded. I haven't tried it but technically speaking it might work. I think though it looks awkward and my opinion is that the alternative is better. - defining features in the virtual workspace's Cargo.toml doesn't work (thought that I might create a feature that will have a dependency on the `node` crate and then not passing the feature to cargo build results in ignoring the `node` crate) - skipping compilation by using an environment variable, read in the build script, that will exit compilation abruptly if not set, but I couldn't make it work. - exclude the crate from the members list and build it specifically by passing `--package minimal-template-node` flag to the `cargo build` command. This has the disadvantage of not allowing IDEs based on rust analyzer to index/compile the node crate. My conclusion is that any option would require two commands to build the template, one with the node and one without, and both must be included in the README or templates usage documentation. If it comes which ones to pick I am in favor of the `default-members` option, which requires minimal intervention and expresses how cargo commands are executed on top of the workspace members, and what's left out from regular usage. ### Testing Testing was conducted as described bellow: - [x] zombienet with `minimal-template-node` , `parachain-template-node` and `polkadot-omni-node`. Things work as expected. - [x] no chopsticks testing was conducted - feels a bit out of scope for OmniNode related docs and overall testing when promoting it over the templates' nodes. - [x] testing the changes for the sync templates workflow (ignore the added comment from the Cargo.tomls, it was removed here on this branch: [99bff3e2](https://github.com/paritytech/polkadot-sdk/pull/5954/commits/99bff3e2 )): [minimal](https://github.com/paritytech-stg/polkadot-sdk-minimal-template/pull/22/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9), [parachain](https://github.com/paritytech-stg/polkadot-sdk-parachain-template/pull/19/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9), [solochain](https://github.com/paritytech-stg/polkadot-sdk-solochain-template/pull/17/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R9). The links correspond to PRs opened by a bot after manually starting the sync-templates workflow on `paritytech-stg` org to test the end result of the `Cargo.toml` changes. --------- Signed-off-by:
Iulian Barbu <iulian.barbu@parity.io> Co-authored-by:
Kian Paimani <5588131+kianenigma@users.noreply.github.com>
-