@@ -15,8 +15,7 @@ When launching a new network, you're likely to use a new runtime. See how to [re
...
@@ -15,8 +15,7 @@ When launching a new network, you're likely to use a new runtime. See how to [re
### Inject runtime in chainspec
### Inject runtime in chainspec
FIXME order?
Ğ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:
Once you updated your session keys, inject the runtime code built with srtool inside the raw chainspec file.
Ensure that the currency type you want has the requirements (TODO explain).
For now, only `gdev` is supported.
For now, only `gdev` is supported.
In the commands that will be indicated afterwards, you will have to replace `CURRENCY` by the
In the commands that will be indicated afterwards, you will have to replace `CURRENCY` by the
...
@@ -109,15 +106,6 @@ The following steps should be completed once you are satisfied with the new live
...
@@ -109,15 +106,6 @@ The following steps should be completed once you are satisfied with the new live
You should rotate session keys for more secured keys produced on the server (the one you used before are still in your develop machine bash history and clipboard).
You should rotate session keys for more secured keys produced on the server (the one you used before are still in your develop machine bash history and clipboard).
TODO explain how with polkadotjs + vpn (?)
Then update the raw chainspec file with your new session keys. (FIXME is this right?)
### Embed the raw chainspec in the binary
TODO embed the raw chain spec in the binary with include_bytes! macro
### Publish image
### 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:
Once you completed all these steps, the other smith can pull the docker image with a genesis containing your bootnode with the correct session keys. They can base their `docker-compose.yml` on the `duniter-validator` template.
Once you completed all these steps, the other smith can pull the docker image with a genesis containing your bootnode with the correct session keys. They can base their `docker-compose.yml` on the `duniter-validator` template.
@@ -4,7 +4,7 @@ Here you will learn how to release a new runtime using `gitlab ci` and `cargo xt
...
@@ -4,7 +4,7 @@ Here you will learn how to release a new runtime using `gitlab ci` and `cargo xt
## Runtime tag and spec version
## Runtime tag and spec version
When launching a new network, you're likely to use a new runtime for the genesis. Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix.
Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix.
1. 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.
1. 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.
1. Check that the [CI on release/runtime-XX00](https://git.duniter.org/nodes/rust/duniter-v2s/-/pipelines?scope=all&page=1&ref=runtime-400)(runtime major release branch) is passing. This is necessary to build the docker images.
1. Check that the [CI on release/runtime-XX00](https://git.duniter.org/nodes/rust/duniter-v2s/-/pipelines?scope=all&page=1&ref=runtime-400)(runtime major release branch) is passing. This is necessary to build the docker images.