diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 1050441fc03fc43dc09959c873bc9a770b49a780..4270de6cdb65efb070a89a564099a62c0acd3065 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -393,7 +393,7 @@ create_release: tags: - kepler -release_gdev_6_specs: +release_gdev_specs: extends: .release_specs needs: - create_release diff --git a/docs/dev/img/pipeline_screenshot.png b/docs/dev/img/pipeline_screenshot.png deleted file mode 100644 index 2c2870de4baa32f9f9f0a5a18bb280c7be926366..0000000000000000000000000000000000000000 Binary files a/docs/dev/img/pipeline_screenshot.png and /dev/null differ diff --git a/docs/dev/img/release-pipeline.png b/docs/dev/img/release-pipeline.png new file mode 100644 index 0000000000000000000000000000000000000000..324206a82193f52932995e194365bcba69ca4b0a Binary files /dev/null and b/docs/dev/img/release-pipeline.png differ diff --git a/docs/dev/release-new-runtime.md b/docs/dev/release-new-runtime.md index 43920e1c5486ba9fee8b8839ef5b05bf98683ece..c272c48510607bf6b4fe01043ee121d2fe1e193e 100644 --- a/docs/dev/release-new-runtime.md +++ b/docs/dev/release-new-runtime.md @@ -1,41 +1,58 @@ -# Release a new runtime +# Release a new Runtime -Here you will learn how to release a new runtime using `gitlab ci` and `cargo xtask`. + -## Runtime tag and spec version +> The following instructions have been described in french at: [Créer une release](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/41). -Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix. +## Process + +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) + +The Runtime is now available on the release page [runtime-800](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-800). -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`. +### New Client -Publish the `runtime-400` branch. Go to the pipelines and run the manual tasks as shown on the screenshot below. +The Client is published as a Docker image. -- `build_release_manual` -- `deploy_docker_release_sha` +You may want to publish a new Client version along with a Runtime update. - +#### New raw specs (optional) -## Release runtime +For a reboot, you will likely want to update the raw specs: -We choose [`xtask`](https://github.com/matklad/cargo-xtask/) to run Rust scripts using `cargo`. To build these scripts, just run: +* 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` -```bash -cargo xtask -h # this will build the scripts and show the available commands -``` +#### New version (mandatory) -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: +Update Client values: -```bash -cargo xtask release-runtime 400 # requires to run docker as non-root user -``` +* update Client version (in `Cargo.toml`) +* update `Cargo.lock` with `cargo build` + +#### Publish Docker image -This command does the following things (use your system monitor to track the progress as it produces not log): +Commit everything and push the branch: -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` +* 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. + +## Runtime tag and spec version + +Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix. -This release will trigger a GitLab CI publishing a docker image of the Substrate client with embeded runtime. \ No newline at end of file +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.