@@ -7,55 +7,26 @@ Launching a new live network is more difficult than spawning a local blockchain.
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`
- make sure you can run docker as non-root user with `docker info` or so
## Preparation
### Runtime tag
When launching a new network, you're likely to use a new runtime. See how to [release a new runtime](./release-new-runtime.md).
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 or minor change.
### Inject runtime code in chainspec
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 master](https://git.duniter.org/nodes/rust/duniter-v2s/-/pipelines?scope=all&page=1&ref=master) is passing. This is necessary to build the docker images.
1. Increment the `spec_version` in the code. Example `spec_version: 300` -> `spec_version: 400`.
At this point, you might want to merge this commit in master and publish the branch (TODO automate).
### Release tasks
We choose [`xtask`](https://github.com/matklad/cargo-xtask/) to run Rust scripts using `cargo`. To build these scripts, just run:
FIXME order?
Once you updated your session keys, inject the runtime code built with srtool inside the raw chainspec file.
```bash
cargo xtask # this will build the scripts and show the available commands
```
To interact with GitLab, the `release_runtime` script uses the environment variable `GITLAB_TOKEN` which must contain a token with write permission on the repository. Go to your [personal access token preferences](https://git.duniter.org/-/profile/personal_access_tokens) to generate one and `export` it (you might want to add it to your `.bashrc`). You can then run this command:
```bash
cargo xtask release-runtime 400 # requires to run docker as non-root user
This command does the following things (use your system monitor to track de progress as it produces not log):
1. download the [`paritytech/srtool`](https://docs.substrate.io/reference/command-line-tools/srtool/)(Substrate Runtime TOOLbox) docker image (about 2 minutes with a good connection). It is a docker container enabling to build the Substrate WebAssembly runtime in a deterministic way (machine-independant).
1. build gdev runtime in release mode using `srtool` (about 5 minutes depending on your computing power). The target is put in the `runtime/gdev/target` folder (about 2GB).
1. generate release notes using the template in `xtask/res`
1. publish the relase with the notes on GitLab using your `GITLAB_TOKEN`
### Substrate client docker image
Go to the pipeline and run the manual tasks as shown on the below screenshot.
then on the server, launch the compose file from the the distribution folder's root:
```bash
ssh <server>
cd"<path/to/dist/folder>"
docker compose up -d
```
This is the first node of the new live network.
## Finalization
The following steps should be completed when you are satisfied with the network.
The following steps should be completed once you are satisfied with the new live network.
### Rotate session keys
You should rotate session keys for more secured keys (the one you used before are still in your bash history and your clipboard and could have been intercepted by an attacker). Update the raw chainspec json file with your new session keys.
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
TODO explain how with polkadotjs + vpn (?)
### Inject chainspec
Then update the raw chainspec file with your new session keys. (FIXME is this right?)
Once you updated your session keys, inject the runtime code inside the raw chainspec.
### Embed the raw chainspec in the binary
TODO embed the raw chain spec in the binary with include_bytes! macro
Here you will learn how to release a new runtime using `gitlab ci` and `cargo xtask`.
## 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.
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. Increment the `spec_version` in the code. Example `spec_version: 300` -> `spec_version: 400`.
Publish the `runtime-400` branch. Go to the pipelines and run the manual tasks as shown on the screenshot below.
We choose [`xtask`](https://github.com/matklad/cargo-xtask/) to run Rust scripts using `cargo`. To build these scripts, just run:
```bash
cargo xtask -h# this will build the scripts and show the available commands
```
To interact with GitLab, the `release_runtime` script uses the environment variable `GITLAB_TOKEN` which must contain a token with write permission on the repository. Go to your [personal access token preferences](https://git.duniter.org/-/profile/personal_access_tokens) to generate one and `export` it (you might want to add it to your `.bashrc`). You can then run this command:
```bash
cargo xtask release-runtime 400 # requires to run docker as non-root user
```
This command does the following things (use your system monitor to track the progress as it produces not log):
1. Download the [`paritytech/srtool`](https://docs.substrate.io/reference/command-line-tools/srtool/)(Substrate Runtime TOOLbox) docker image (about 2 minutes with a good connection). It is a docker container enabling to build the Substrate WebAssembly runtime in a deterministic way (machine-independant).
1. Build gdev runtime in release mode using `srtool` (about 5 minutes depending on your computing power). The target is put in the `runtime/gdev/target` folder (about 2GB).
1. Generate release notes using the template in `xtask/res`
1. Publish the release with the notes on GitLab using your `GITLAB_TOKEN`
This release will trigger a GitLab CI publishing a docker image (TODO of what?).
