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

Add development chain-spec file for minimal/parachain templates for Omni Node compatibility #6529

Open
wants to merge 68 commits into
base: master
Choose a base branch
from

Conversation

EleisonC
Copy link

Description

This PR adds development chain specs for the minimal and parachain templates. #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.
  1. 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.
  • Ensure you have set up your runtimes parachain-template-runtime and minimal-template-runtime
  • Ensure you have installed the nodes required ie parachain-template-node and minimal-template-node
  • Set up Zombinet
  • For running the parachains, you will need to install the polkadot cargo install --path polkadot remember from the polkadot-SDK master branch.
  • Inside the template folders minimal or parachain, run the command to start with Zombienet with Omni Node, Zombienet with minimal-template-node or Zombienet with parachain-template-node

Include your leftover TODOs, if any, here.

  • Test the syncing of chain specs with runtime's code.

@cla-bot-2021
Copy link

cla-bot-2021 bot commented Nov 18, 2024

User @EleisonC, please sign the CLA here.

@iulianbarbu iulianbarbu self-requested a review November 19, 2024 15:03
@iulianbarbu iulianbarbu added T17-Templates This PR/Issue is related to templates T11-documentation This PR/Issue is related to documentation. labels Nov 19, 2024
@iulianbarbu iulianbarbu added the R0-silent Changes should not be mentioned in any release notes label Nov 19, 2024
Copy link
Contributor

@iulianbarbu iulianbarbu left a comment

Choose a reason for hiding this comment

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

Thanks @EleisonC ! Left a few comments for now.
Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

templates/minimal/zombienet.toml Outdated Show resolved Hide resolved
templates/parachain/zombienet.toml Outdated Show resolved Hide resolved
@EleisonC
Copy link
Author

Thanks @EleisonC ! Left a few comments for now. Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

Hey @iulianbarbu that is what I am looking into today. Do you have any pointers you'd like me to know as I move forward?

@iulianbarbu
Copy link
Contributor

Thanks @EleisonC ! Left a few comments for now. Looking forward to the README updates & btw, have you clarified how to make a rust test for the chain specs?

Hey @iulianbarbu that is what I am looking into today. Do you have any pointers you'd like me to know as I move forward?

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

@EleisonC
Copy link
Author

Hey @iulianbarbu one last question it's okay if I placed the test folder/file under the nodes folder/file. if not is there a better place

@iulianbarbu
Copy link
Contributor

iulianbarbu commented Nov 21, 2024

Hey @iulianbarbu one last question it's okay if I placed the test folder/file under the nodes folder/file. if not is there a better place

Hmm, thought about placing it under runtime initially. I think it makes more sense to place it under runtime so that if anything changes here, running the tests for the crate would fail because the changes will not be inline with dev_chain_spec.json. The node uses the logic defined in the runtime, so it would benefit from the runtime test, but not directly. I don't think we need to add a test on the same lines in the templates' nodes crate either because these nodes aren't depending on the dev_chain_spec.json file. Only OmniNode depends on this file being in sync with the runtime, and that not because it would fail otherwise, but because it would start an outdated version.

@EleisonC
Copy link
Author

EleisonC commented Nov 25, 2024

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top
Is it the value of code? Because the test fails when I compare the code value of the two chain spec files.
let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis");
But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

@EleisonC
Copy link
Author

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file and load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top Is it the value of code? Because the test fails when I compare the code value of the two chain spec files. let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis"); But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

I figured out my problem was around decoding a Hex String to bytes. I can now properly traverse the values of the Top section and find the code for that spec file

@iulianbarbu
Copy link
Contributor

From the top of my head I thought about adding an integration test. You could build a ChainSpec as described here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/parachain/node/src/chain_spec.rs#L36, and then call as_json -> and then convert it to serde_json::Value, and then read the newly added file an

d load its content as a serde_json::Value and then compare the two.

Hey @iulianbarbu regarding comparing the two I am a bit stuck on what to compare. From my research I would think it's other the code or value of top Is it the value of code? Because the test fails when I compare the code value of the two chain spec files. let test_runtime_code = test_json_value // .get("genesis") // .expect("failed to extract genesis") // .get("runtimeGenesis") // .expect("failed to extract runtimeGenesis from genesis") // .get("code") // .expect("failed to extract code from runtimeGenesis"); But the code value of test_runtime and the existing file do not match. Hence wondering if it would be the Top value to or maybe I am missing a step of conversion somewhere

I figured out my problem was around decoding a Hex String to bytes. I can now properly traverse the values of the Top section and find the code for that spec file

Happy to hear you've sorted it out! I've noticed that in some tests we don't compare the code portions of the generated chain specs, and that's mainly because they are not super relevant for the test case. For this test though I think that it is relevant, to ensure generated chain specs correspond to the runtimes in the CI.

Some other good news is that once we'll have these chain specs we'll be able to easily run in the CI the omni_node_* tests like this one: https://github.com/paritytech/polkadot-sdk/blob/master/templates/zombienet/tests/smoke.rs#L160. We can update them in a follow up, no need to consider them right now, but it is up to you.

As usual, LMK in case of blockers, happy to take a look.

@EleisonC
Copy link
Author

Hey @iulianbarbu,
I added a test and would appreciate it if you could look at it and approve it before I add the one for the para chain. Additionally, I added the test folder to nodes because I was encountering setup issues.

Copy link
Contributor

@iulianbarbu iulianbarbu left a comment

Choose a reason for hiding this comment

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

Can you please regenerate the dev_chain_spec.json for minimal (for now) after building the minimal/runtime with cargo build? I wonder if you built the runtime with --release and then generated the dev_chain_spec.json. It makes sense according to the README, but we run the tests with the testnet profile, which enables the debug symbols, and I think the chain spec code section differs based on the profile. I would be curious to run the test again after you regenerate the dev_chain_spec.json, and also see if regenerating on my machine results in a different code section, or chain spec altogheter.

templates/minimal/node/tests/validate_dev_chain_spec.rs Outdated Show resolved Hide resolved
templates/minimal/node/tests/validate_dev_chain_spec.rs Outdated Show resolved Hide resolved
templates/minimal/node/tests/validate_dev_chain_spec.rs Outdated Show resolved Hide resolved
templates/minimal/node/Cargo.toml Outdated Show resolved Hide resolved
@EleisonC
Copy link
Author

@iulianbarbu Update: I am trying to run the workflow steps locally using Podman and Srtool, as I hope to compare the wasm binary (spec chain.json file) that I build locally. Do you think the Rust version used in the workflow could have any impact? I'm just curious. I realize that’s what Srtool is designed to address, along with the differences between Podman and Docker that I'm attempting to replicate. However, I want to be confident about this process.

@iulianbarbu
Copy link
Contributor

Hi @EleisonC ! I am expecting the chain specs to be the same if generated with any 'chain-spec-builder' version (no matter how it got built).

Can you compare the wasm blob generated on the CI with the one generated on your machine? Alternatively, if they differ, I would compare wasm runtimes generated by two runs of the GH action you introduced (by downloading manually the wasms from action storage, if you have access to the action output). I am assuming they will be the same at least when built on the CI for multiple times from the same git commit.

@skunert any idea why the chain specs differ even if both were built based on the same runtime, built with srtool?

@skunert
Copy link
Contributor

skunert commented Dec 17, 2024

This is not related to the rust version or the chainspec itself. The runtime wasm is the only changing factor here. The rust version is handled by the docker image pulled by SRTool.

What happened here is different. When building this branch locally I arrived at this summary from SRTool (parachain template runtime):

✨ Your Substrate WASM Runtime is ready! ✨
✨ WASM  : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.wasm
✨ Z_WASM: ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm
Summary generated with srtool v0.17.0 using the docker image paritytech/srtool:1.81.0:
 Package     : parachain-template-runtime v0.0.0
 GIT commit  : 546ba5655f60f9831e99fda3d2b577ddf40205ef
 GIT tag     : v1.16.0-approval-voting
 GIT branch  : add-dev-chain-spec
 Rustc       : rustc 1.81.0 (eeb90cda1 2024-09-04)
 Time        : 2024-12-17T14:36:18Z

== Compact
 Version          : parachain-template-runtime-1 (parachain-template-runtime-0.tx1.au1)
 Metadata         : V14
 Size             : 4.41 MB (4621253 bytes)
 setCode          : 0x1548c48d31461c75f3ea76e6ae61f54f575ce077ab41bee260782a073cdb5f3f
 authorizeUpgrade : 0x55d46074a49ca56692ec31375746f0f746a5b0f649d41dbcdbeb70986dce9b0b
 IPFS             : QmaJMVKPqAcG9W4H3Q4KJBnXM7kzZFJBzF3wNcoLEBJZu9
 BLAKE2_256       : 0x3d18a9732ea4e61285a9e5e33632109af7e2e84e7184a5963009c0c6fd649e41
 Wasm             : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.wasm

== Compressed
 Version          : parachain-template-runtime-1 (parachain-template-runtime-0.tx1.au1)
 Metadata         : V14
 Size             : 963.69 kB (986814 bytes)
 Compression      : 78.65%
 setCode          : 0xa01a1db41163f56cff8838ce27001157a08919061e159bcdf57f1df7b55e5416
 authorizeUpgrade : 0xde0908e96c72608b3b392b34997ec707de13c91df924fe9815faede67b35a6cf
 IPFS             : QmbdeeheW2ZjsxmNr8dAhbq67CLsGN1E4G7boUNZ4b5uJs
 BLAKE2_256       : 0xc5e7b355e18c5a77fc8ced1ef228631b504e81cde98aea1b332a7df086809926
 Wasm             : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm

We see that the Blake2 hash of the runtime is 0xc5e7b355e18c5a77fc8ced1ef228631b504e81cde98aea1b332a7df086809926. In contrast in this line of the CI Job we see that the hash of the runtime build by CI is 0xd7f7a9dd1ab203a0df5237c643844cfdaa64521320f835b5f32404fa99c7be40.

The reason is that CI merges the current branch with master for the job. Master had some recent changes to the parachain template runtime which resulted in a different WASM blob. After merging master I arrive at the same hash as CI:

✨ Your Substrate WASM Runtime is ready! ✨
✨ WASM  : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.wasm
✨ Z_WASM: ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm
Summary generated with srtool v0.17.0 using the docker image paritytech/srtool:1.81.0:
 Package     : parachain-template-runtime v0.0.0
 GIT commit  : 546ba5655f60f9831e99fda3d2b577ddf40205ef
 GIT tag     : v1.16.0-approval-voting
 GIT branch  : add-dev-chain-spec
 Rustc       : rustc 1.81.0 (eeb90cda1 2024-09-04)
 Time        : 2024-12-17T18:54:59Z

== Compact
 Version          : parachain-template-runtime-1 (parachain-template-runtime-0.tx1.au1)
 Metadata         : V14
 Size             : 4.41 MB (4621228 bytes)
 setCode          : 0xbfe2d975e536b433bdd4883da768d6bf538eda1670f8bd7373c0dfdbabb76f14
 authorizeUpgrade : 0xa96a217a964c9734620e430081adfffa4abf971b66e5fb60969b18878c464bee
 IPFS             : QmYSNTQisEr3gyxzxFDhmg1XugwknQ4njjRZ4bUKvNbaLQ
 BLAKE2_256       : 0xf9ce00caa1b5d5a9b5d5d464bd13caf5b1b821248a8695ec28edf99f5adb2449
 Wasm             : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.wasm

== Compressed
 Version          : parachain-template-runtime-1 (parachain-template-runtime-0.tx1.au1)
 Metadata         : V14
 Size             : 963.72 kB (986850 bytes)
 Compression      : 78.65%
 setCode          : 0x9bb53a5bb708fceb70940a1fd0de435eb2ecc08b0748cd3840fad3e69b68544e
 authorizeUpgrade : 0xf0791b1c05bf46e6ce32bf452ce20966b62f9a4937911948312265b8914ec14c
 IPFS             : QmaUPBrdJgx7VxeVgHDTnAL8541eTfxHCFgyMSLNDEWECq
 BLAKE2_256       : 0xd7f7a9dd1ab203a0df5237c643844cfdaa64521320f835b5f32404fa99c7be40
 Wasm             : ./templates/parachain/runtime/target/srtool/release/wbuild/parachain-template-runtime/parachain_template_runtime.compact.compressed.wasm

@EleisonC
Copy link
Author

Hey @iulianbarbu I uploaded a new dev_chain_spec for Parachain. I checked it against the out come of the previous run, and it looks hopeful. Getting around the minimal one

@EleisonC
Copy link
Author

We see that the Blake2 hash of the runtime

@iulianbarbu also I still get different hashes for my minimal. Clearing my cache and all to give it another try

@EleisonC
Copy link
Author

EleisonC commented Dec 19, 2024

Hey @skunert tried the same with the minimal but I keep on getting a BLAKE2_256 BLAKE2_256 : 0x5a8dacd160f12a36fd0a7257606283baefbba77104cd67ced0b567b4407aa817 value that is not exact as the CI run

✨ Your Substrate WASM Runtime is ready! ✨
✨ WASM  : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.wasm
✨ Z_WASM: ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm
fatal: No names found, cannot describe anything.
Summary generated with srtool v0.17.0 using the docker image paritytech/srtool:1.81.0:
 Package     : minimal-template-runtime v0.0.0
 GIT commit  : 278324c7ff3acc968adcf414b52507111b3e68d4
 GIT tag     : 
 GIT branch  : add-dev-chain-spec
 Rustc       : rustc 1.81.0 (eeb90cda1 2024-09-04)
 Time        : 2024-12-19T17:07:49Z

== Compact
 Version          : minimal-template-runtime-0 (minimal-template-runtime-1.tx1.au1)
 Metadata         : V14
 Size             : 1004.33 kB (1028437 bytes)
 setCode          : 0x8dc8fbbdbc4fb058e076d915175b9363091f9af13cbaf2e78cdaa9bd6f94dc95
 authorizeUpgrade : 0xe91aed2e617f6243522dab081573bb50292877970bc83146e004eb8613cb0cc4
 IPFS             : QmU5nuekV7ca4ShAFU2uTgzz13jzEW3nAfPcwEFPFGHWsV
 BLAKE2_256       : 0xf80020328d1afd7bbb88effab38bbfdaab67868cc7e94c66abe4e10da17e96e5
 Wasm             : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.wasm

== Compressed
 Version          : minimal-template-runtime-0 (minimal-template-runtime-1.tx1.au1)
 Metadata         : V14
 Size             : 262.30 kB (268593 bytes)
 Compression      : 73.89%
 setCode          : 0x6a57cc079da9f700700e64e55eb30d765b06caee2b307c10229d67eaf36cfac8
 authorizeUpgrade : 0x704531ce06cacf0c133e9f8644c534930509045848c9d8507dc626eb2c98e9d7
 IPFS             : QmXWdrLUvaM7ZQ9F6bUzKxUADfhWojU1y1MNichrozFci2
 BLAKE2_256       : 0x5a8dacd160f12a36fd0a7257606283baefbba77104cd67ced0b567b4407aa817
 Wasm             : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm

I cleared my cache and ran the command with the latest master, but I'm still building that WASM blob. Any pointers on what I might be missing out?

@skunert
Copy link
Contributor

skunert commented Dec 19, 2024

I am getting the same as your posted snippet from CI:

✨ Your Substrate WASM Runtime is ready! ✨
✨ WASM  : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.wasm
✨ Z_WASM: ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm
Summary generated with srtool v0.17.0 using the docker image paritytech/srtool:1.81.0:
 Package     : minimal-template-runtime v0.0.0
 GIT commit  : f0a3f18168f27f66f1cab052b402b67b0f4a5dd7
 GIT tag     : v1.16.0-approval-voting
 GIT branch  : add-dev-chain-spec
 Rustc       : rustc 1.81.0 (eeb90cda1 2024-09-04)
 Time        : 2024-12-19T18:25:29Z

== Compact
 Version          : minimal-template-runtime-0 (minimal-template-runtime-1.tx1.au1)
 Metadata         : V14
 Size             : 1004.33 kB (1028437 bytes)
 setCode          : 0x8dc8fbbdbc4fb058e076d915175b9363091f9af13cbaf2e78cdaa9bd6f94dc95
 authorizeUpgrade : 0xe91aed2e617f6243522dab081573bb50292877970bc83146e004eb8613cb0cc4
 IPFS             : QmU5nuekV7ca4ShAFU2uTgzz13jzEW3nAfPcwEFPFGHWsV
 BLAKE2_256       : 0xf80020328d1afd7bbb88effab38bbfdaab67868cc7e94c66abe4e10da17e96e5
 Wasm             : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.wasm

== Compressed
 Version          : minimal-template-runtime-0 (minimal-template-runtime-1.tx1.au1)
 Metadata         : V14
 Size             : 262.30 kB (268593 bytes)
 Compression      : 73.89%
 setCode          : 0x6a57cc079da9f700700e64e55eb30d765b06caee2b307c10229d67eaf36cfac8
 authorizeUpgrade : 0x704531ce06cacf0c133e9f8644c534930509045848c9d8507dc626eb2c98e9d7
 IPFS             : QmXWdrLUvaM7ZQ9F6bUzKxUADfhWojU1y1MNichrozFci2
 BLAKE2_256       : 0x5a8dacd160f12a36fd0a7257606283baefbba77104cd67ced0b567b4407aa817
 Wasm             : ./templates/minimal/runtime/target/srtool/release/wbuild/minimal-template-runtime/minimal_template_runtime.compact.compressed.wasm

Did you maybe mix up your build command? I am using srtool build --package minimal-template-runtime --runtime-dir ./templates/minimal/runtime --root on your branch here. Please stop merging master, I think your are having a different issue this time.

@EleisonC
Copy link
Author

Did you maybe mix up your build command? I am using srtool build --package minimal-template-runtime --runtime-dir ./templates/minimal/runtime --root on your branch here.

sorry should have added the commands srtool build --package minimal-template-runtime --runtime-dir ./templates/minimal/runtime --root is what I used same as the one you used @skunert

@skunert
Copy link
Contributor

skunert commented Dec 19, 2024

Hmm at this point its not really possible for me to say why you are ending up with a different hash. Have you merged master here in the PR but not pulled to your local machine, so that you are on a different commit? Or your have local changes?

These issues aside, after thinking about it more I am against introducing this CI job. Everytime there is a minor change in any of the runtime related code of polkadot-sdk, the generated WASM blob will change, forcing developers to update this chain-spec constantly (because the job will fail).

A better way to handle this IMO is to just have the chainspec committed and update it manually. For sure this is annoying and the spec could potentially go out of sync. But having an extra CI job for it seems like overkill.

I am sorry for the work you have already put into the CI job. Can you please remove it?

@EleisonC
Copy link
Author

Hmm at this point its not really possible for me to say why you are ending up with a different hash. Have you merged master here in the PR but not pulled to your local machine, so that you are on a different commit? Or your have local changes?

Hey @skunert cc: @iulianbarbu . I appreciate the help and the time you were able to allocate to this. I want to first address this issue ☝️, After thorough testing, I can confirm that this issue has been resolved and the workflows run okay Workflow Run Personal Fork. The CI job and local development environments now consistently produce the same Blake2_256 hash for the runtime WASM blob, ensuring alignment with the Polkadot SDK master's Runtime determined using the Srtool.
cmd-ran srtool build --package minimal-template-runtime --runtime-dir ./templates/minimal/runtime --root

These issues aside, after thinking about it more I am against introducing this CI job. Everytime there is a minor change in any of the runtime related code of polkadot-sdk, the generated WASM blob will change, forcing developers to update this chain-spec constantly (because the job will fail).

A better way to handle this IMO is to just have the chainspec committed and update it manually. For sure this is annoying and the spec could potentially go out of sync. But having an extra CI job for it seems like overkill.

I am sorry for the work you have already put into the CI job. Can you please remove it?

I completely understand your concern regarding the added maintenance burden of a CI job that enforces frequent updates to the chain spec due to minor runtime changes. Your suggestion to commit the chain spec manually and update it as needed is reasonable; however, I'd like to propose an enhancement that maintains the benefits of automation while keeping the workflow lightweight and developer-friendly.

  1. The CI pipeline can include a lightweight job
    Add a job to verify if the code field inside the genesis section of the committed chain spec matches the corresponding field in the CI-generated spec file. If there's a mismatch, the job should fail with clear, actionable guidance for developers to update the chain spec. This balances automation and developer effort without introducing unnecessary overhead. This could be use full in situation where a runtime was probably build the wrong way or with outdated version of staging or diff srtool version used and might not realise.

  2. Introduce a Shell script for easier updates
    Provide a shell script to streamline the process of installing srtool, pulling updates, building, and updating the dev chain spec code. This simplifies the workflow for developers, requiring only a single executable shell script to update only requiring them to then push changes.
    By leveraging this, the CI workflow can serve as an attestation mechanism to ensure that the dev chain is built using the same runtime as Polkadot SDK.

@EleisonC EleisonC requested a review from iulianbarbu December 20, 2024 16:50
@skunert
Copy link
Contributor

skunert commented Dec 20, 2024

Hey,

the problem with (1) is that this will not break now and then when there is a change to the parachain template runtime, that would be okay. But polkadot-sdk is merging lots of commits per week. Imagine someone is creating a pull request to modify some log line here for example. In their pull request the CI job would fail because that code is a dependency of parachain-template-runtime and they would need to regenerate the chain-spec.

Whe question is also what the benefit of keeping the chain-spec up to date in polkadot-sdk really is. Once per release these two template repositories are synchronized with the current state of polkadot-sdk:

This is where I expect new users to go to try out these templates. Ideally, the job that synchronizes the templates with the polkadot-sdk would generate the chain-specs from the current runtime. This way, the chain-specs in the template repositories would be correct on every release.

I like your proposal of (2), having a script in the repo to generate these chainspecs. The flow could look like this:

  • Have a manually generated chain-spec in polkadot-sdk
  • Have a script that refreshes the chain-spec in polkadot-sdk (gets copied over to the template repos)
  • The job that syncs the code from here into the template repositories regenerates the chain-spec and makes sure that it is up-to-date in the template repos.

This way the chain-spec in the template repositories is always up-to-date and we don't have the burden of this constantly failing CI job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes 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.

4 participants