From 313f6da1be68af716589b37509fbeba3468c733e Mon Sep 17 00:00:00 2001 From: Hugo Trentesaux <hugo@trentesaux.fr> Date: Wed, 25 Sep 2024 15:26:11 +0200 Subject: [PATCH] wip mark parts of doc to rewrite --- docs/dev/launch-a-live-network.md | 8 +++--- docs/dev/release-new-runtime.md | 41 +++++++++++++++++++------------ 2 files changed, 29 insertions(+), 20 deletions(-) diff --git a/docs/dev/launch-a-live-network.md b/docs/dev/launch-a-live-network.md index fca4accb5..9d7f50d6c 100644 --- a/docs/dev/launch-a-live-network.md +++ b/docs/dev/launch-a-live-network.md @@ -4,7 +4,7 @@ Launching a new live network is more difficult than spawning a local blockchain. ## Requirements -In order to build in a standardized environment, you need Docker. +In order to build in a standardized environment, you need Docker. - see docker docs to [install docker](https://docs.docker.com/engine/install/) - make sure you can run docker as non-root user with `docker info` or so @@ -15,10 +15,10 @@ When launching a new network, you're likely to use a new runtime. See how to [re ### Inject runtime in chainspec -ĞDev runtime is automatically embeded in the raw chainspec with the `include_bytes!` macro. An other way to inject the runtime is to use "inject-runtime-code" xtask: +~~ĞDev runtime is automatically embeded in the raw chainspec with the `include_bytes!` macro. An other way~~ to inject the runtime is to use "inject-runtime-code" xtask: ```bash -cargo xtask inject-runtime-code --runtime runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm --raw-spec resources/gdev-raw.json +cargo xtask inject-runtime-code --runtime runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm --raw-spec resources/gdev-raw.json ``` ## Bootstraping @@ -108,7 +108,7 @@ You should rotate session keys for more secured keys produced on the server (the ### Publish image -With these new session keys in the chainspec and the runtime build with srtool, you can release the new runtime again with: +With these new session keys in the chainspec and the runtime build with srtool, you can release the new runtime again with: ```bash cargo xtask release-runtime 400 diff --git a/docs/dev/release-new-runtime.md b/docs/dev/release-new-runtime.md index c272c4851..9df2d9428 100644 --- a/docs/dev/release-new-runtime.md +++ b/docs/dev/release-new-runtime.md @@ -10,12 +10,14 @@ Example for `runtime-800`. ### New release with new Runtime -* create a `release/runtime-800` branch locally -* update the values: - * update spec version (in `runtime/<currency>/src/lib.rs`) - * eventually update `gdev.yml` (smiths, tech. committee, ...) -* push the `release/runtime-800` branch - * in the CI/CD, wait for `Create release` button to be available and click on it (see above screenshot) +- create a `release/runtime-800` branch locally [FIXME network/gdev-800] +- update the values: + - update spec version (in `runtime/<currency>/src/lib.rs`) + - eventually update `gdev.yml` (smiths, tech. committee, ...) [FIXME this should be only for bootstraping new network] + - [+ update the Cargo.lock file] + - [+ FIXME milestones should be updated before that] +- push the `release/runtime-800` branch + - in the CI/CD, wait for `Create release` button to be available and click on it (see above screenshot) The Runtime is now available on the release page [runtime-800](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-800). @@ -24,30 +26,33 @@ The Runtime is now available on the release page [runtime-800](https://git.dunit The Client is published as a Docker image. You may want to publish a new Client version along with a Runtime update. +[NOTE only necessary in the case of breaking changes in the API] #### New raw specs (optional) +[FIXME we should split the release runtime doc and the bootstrap network doc] + For a reboot, you will likely want to update the raw specs: -* in the CI/CD, wait for `release_gdev_specs` button to be available and click on it -* in the CI/CD, wait for `release_gtest_specs` button to be available and click on it -* wait for both jobs to finish -* update the Client raw specs with `cargo xtask update-raw-specs runtime-800` +- in the CI/CD, wait for `release_gdev_specs` button to be available and click on it +- in the CI/CD, wait for `release_gtest_specs` button to be available and click on it +- wait for both jobs to finish +- update the Client raw specs with `cargo xtask update-raw-specs runtime-800` #### New version (mandatory) Update Client values: -* update Client version (in `Cargo.toml`) -* update `Cargo.lock` with `cargo build` - +- update Client version (in `Cargo.toml`) +- update `Cargo.lock` with `cargo build` + #### Publish Docker image Commit everything and push the branch: -* in the CI/CD, a new pipeline has been launched -* you can stop jobs `create_g1_data`, `gdev_srtool`, `gtest_srtool` (won't be used) -* click on `gdev_docker_deploy` and `gtest_docker_deploy` +- in the CI/CD, a new pipeline has been launched +- you can stop jobs `create_g1_data`, `gdev_srtool`, `gtest_srtool` (won't be used) +- click on `gdev_docker_deploy` and `gtest_docker_deploy` The Docker images should now be available at: https://hub.docker.com/r/duniter/duniter-v2s-gdev/tags. @@ -56,3 +61,7 @@ The Docker images should now be available at: https://hub.docker.com/r/duniter/d Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix. Make sure to move any issue or merge request assigned to the choosen milestone `runtime-xxyy` to the next one. This prevents from forgetting unfinished work. + +## Submit the runtime upgrade proposal + +Releasing a new runtime creates a Gitlab release page which contains everything needed to submit a runtime upgrade proposal and upload the new runtime when it gets accepted. -- GitLab