v0.1.0: ready to replace existing substrate subcommand

[liamaharon]

Standalone try-runtime-cli with feature parity with the existing substrate subcommand.

You can install the cli binary built from this branch to your path to play with by running

$ cargo install --git https://github.com/paritytech/try-runtime-cli --branch liam-v0.1.0
$ try-runtime --help
$ try-runtime on-runtime-upgrade --help
...etc

Once merged, we can deprecate & cease development of the try-runtime subcommand in substrate and polkadot and move development entirely to this repo.

Partial paritytech/substrate#12975

• Update to work with substrate master
• Update on_runtime_upgrade, execute_block commands and internal logic to feature parity with substrate
• Add OffchainWorker command
• Add FollowChain command
• Add CreateSnapshot command
• Migrate tests from Substrate to this repo
  • Migrate
  • Merge test-utils: programatically spawn dev nodes substrate#14704
• Update readme.md, make sure docs are tidy and work well
  • Migrate docs
  • Add simple readme
• Set up reasonable Github Actions CI
  • Rust cargo fmt and clippy
  • Auto deploy docs to Github Pages on merge to main
  • Runs tests I'm experiencing issues running tests in Github Actions. Devops team is probably going to completely re-do the CI/CD here here (seems they're already playing with something), so I'm not going to spend more time trying to fix this.

A note about fast-forward

I have intentionally left fast-forward out of this PR.

It's not documented or really working in substrate currently, the idea of this PR is just to shift all stable features to this repo so we can continue development from here and deprecate try-runtime-cli in substrate.

I plan to work on fast-forward in a seperate PR, and only merge it when it is in a state where it is easy enough to use with any substrate based chain and well documented.

TODO before merge

• change docs github action to use main branch

[pmikolajczyk41]

I've also one general comment about substrate dependency: I clearly see a reason for depending on the master branch in the Substrate repository, but I also see a big problem for anybody who runs chain that is based on an older Substrate version (essentially any prod chain)

it's out of the scope of this PR, but I would definitely spend some time on discussing how this tool should be versioned; maybe adding tags for polkadot-v0.9.x is enough

[liamaharon]

I've also one general comment about substrate dependency: I clearly see a reason for depending on the master branch in the Substrate repository, but I also see a big problem for anybody who runs chain that is based on an older Substrate version (essentially any prod chain)

it's out of the scope of this PR, but I would definitely spend some time on discussing how this tool should be versioned; maybe adding tags for polkadot-v0.9.x is enough

SGTM, let's follow polkadot conventions.