Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

templates: make node compilation optional #5954

Merged

Conversation

iulianbarbu
Copy link
Contributor

@iulianbarbu iulianbarbu commented Oct 7, 2024

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:

  • zombienet with minimal-template-node , parachain-template-node and polkadot-omni-node. Things work as expected.
  • 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.
  • testing the changes for the sync templates workflow (ignore the added comment from the Cargo.tomls, it was removed here on this branch: 99bff3e): minimal, parachain, solochain. 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>
@iulianbarbu iulianbarbu requested review from a team as code owners October 7, 2024 15:44
@iulianbarbu iulianbarbu self-assigned this Oct 7, 2024
@iulianbarbu iulianbarbu marked this pull request as draft October 8, 2024 09:49
@iulianbarbu iulianbarbu removed request for a team October 8, 2024 09:49
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
This increases CI time but for a good reason. We want to ensure
parachains pick up the finalized block info from the relay chain.

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
@iulianbarbu iulianbarbu added the T17-Templates This PR/Issue is related to templates label Oct 22, 2024
iulianbarbu and others added 8 commits October 22, 2024 15:30
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
@iulianbarbu iulianbarbu marked this pull request as ready for review October 22, 2024 20:39
@paritytech-review-bot paritytech-review-bot bot requested a review from a team October 22, 2024 20:40
@@ -21,15 +21,28 @@ path = "bin/main.rs"
name = "chain-spec-builder"

[lib]
crate-type = ["rlib"]
# Docs tests are not needed since the code samples that would be executed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure why this is needed; anything in docify::embed already has a ignore (for the opposite, you have docify::embed_run!).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is about compiling test snippet not running it.

docify::embed still compiles the snippet, and since we use the trick with bash! macro (which is inaccessible in doc context), compilation would fail.

Copy link
Contributor Author

@iulianbarbu iulianbarbu Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding on top of what @michalkucharczyk said, docify::embed in context of markdown will use rust lang instead of ignore, which will make the sample a doc test. It might insert ignore accordingly for general public/crate-level docs from .rs files (which I haven't tested), so this can be considered a bug. Also, embedding in markdown files can not use embed_run. I tried that previously and generating the readme fails with an error at compile time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, adding something like below in the README (to disable the doc test), will disable the embedding:

\`\`\`ignore
<!-- docify::embed(file_path, name_of_the_export) -->
\`\`\`

@@ -28,6 +31,53 @@ const DUMMY_PATH: &str = "fake-runtime-path";

const OUTPUT_FILE: &str = "/tmp/chain_spec_builder.test_output_file.json";

const RUNTIME_PATH: &str = unwrap_option_str(substrate_test_runtime::WASM_BINARY_PATH);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow-up:

there is some code in multiple places in polkadot-sdk that reads the cargo metadata, finds the target dir, and from there, tries to find the wasm path.

If we have this new const exported by substrate-wasm-builder, it can likely simplify that code.

Example from my code:

https://github.com/iulianbarbu/polkadot-sdk/blob/8b4884dc8a9d60d09d61b08ada0e645121c0d6b8/docs/sdk/src/guides/your_first_node.rs#L146-L159

cc @pepoviola and @pgherveou I think I have seen this in your recent PRs.

#[docify::export]
fn cmd_display_preset() -> String {
bash!(
chain-spec-builder display-preset -r $RUNTIME_PATH -p "staging"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does $RUNTIME_PATH get resolved here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


```sh
cargo build --release
cargo build -p parachain-template-runtime --release
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
cargo build -p parachain-template-runtime --release
cargo build --release

Right? it should be the same.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just nit picking in the overall direction that cargo build should just build the runtime.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 51c1814.


```sh
cargo install --path node
polkadot-omni-node --chain <path/to/chain_spec.json>
Copy link
Contributor

@kianenigma kianenigma Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The OmniNode setup here should not demonstrate a broken command, instead it should:

  1. explain that a parachain cannot progress without relay chain, which we can only setup with ZN
  2. use --dev-block-time --tmp here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: 51c1814

Ok(())
}

#[tokio::test(flavor = "multi_thread")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pepoviola PTAL 🙏


```sh
docker build . -t polkadot-sdk-parachain-template
chain-spec-builder create --relay-chain "rococo-local" --para-id 1000 --runtime \
<target/release/wbuild/path/to/minimal-template-runtime.wasm> named-preset development
Copy link
Contributor

@kianenigma kianenigma Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<target/release/wbuild/path/to/minimal-template-runtime.wasm> named-preset development
./target/release/wbuild/parachain-template-runtime/parachain_template_runtime.wasm named-preset development

This path can be corrected to what will be its true value, as it is predictable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: 51c1814

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
iulianbarbu and others added 6 commits November 1, 2024 16:20
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM post addressing open comments and getting the CI to be green.

This is a great work, thanks @iulianbarbu

I think there has been a lot of learning here: how to properly do good READMEs that are correct, let's learn the recipe, and then apply them to all the rest of OmniTools!

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
@iulianbarbu
Copy link
Contributor Author

iulianbarbu commented Nov 1, 2024

All in all the PR is pending on two outstanding CI issues (observed at least):

  1. The cache is using an outdated version of substrate_test_runtime which will make clippy checks fail, seemingly because of an issue with the forklift usage, but more precisely TBD
  2. Docify will not embed the rust,ignore langs for the code samples from the READMEs, and given we use them for staging-chain-spec-builder's lib.rs docs too, they will be interpreted as docs tests and the CI will run them (even if we use the doctest = false directive in Cargo.toml). The CI runs docs tests with cargo test --doc which will not consider the Cargo.toml directive. We have three options: (1) fix docify, release a new version and consume it by next week release (PR opened here: Fix docify embed in md sam0x17/docify#28), (2) manually insert the rust,ignore langs for the code samples in the README.md, even if regenerating it based on README.docify.md will remove them (this would be a temporary fix until docify is fixed), and (3) revert to exporting the entire tests instead of just their contents. I would choose the second option in the meantime if the first will not be resolved in time.

cc @kianenigma @michalkucharczyk

kianenigma and others added 3 commits November 4, 2024 09:29
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>
@kianenigma kianenigma added this pull request to the merge queue Nov 4, 2024
Merged via the queue into paritytech:master with commit 2a84917 Nov 4, 2024
197 of 198 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T11-documentation This PR/Issue is related to documentation. T17-Templates This PR/Issue is related to templates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make templates node building optional
4 participants