diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 7f2fc29bbb7e340cac366e9902cb07b5ddf9dd7c..2ea12ca8012ac0e702752a8f807a07dcf468ab79 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,28 +19,21 @@ Please read [Developer documentation] before contribute.
- Create a branch based on `master` and prefixed with your nickname. Give your branch a short name indicating the subject.
- Create an MR from your branch to `master`.
-- Never contribute to a branch of ahother contributor! If the contributor make a `git rebase` your commit will be lost !
+- Never contribute to a branch of another contributor! If the contributor makes a `git rebase` your commit will be lost!
- Before you push your commit:
- Apply formatters (rustfmt and prettier) and linter (clippy)
- - Document your code.
+ - Document your code
- Apply the [project's git conventions]
## Merge Process
1. Ensure you rebased your branch on the latest `master` commit to avoid any merge conflicts.
-
-2. Ensure that you respect the [commit naming conventions].
-
-3. Ensure that all automated tests pass with the `cargo test` command.
-
-3. Ensure that the code is well formated `cargo fmt` and comply with the good practices `cargo clippy`. If you have been working on tests, check everything with `cargo clippy --all --tests`.
-
-4. Update the documentation with details of changes to the interface, this includes new environment
- variables, exposed ports, useful file locations and container parameters.
-
-5. Push your branch on the gitlab and create a merge request. Briefly explain the purpose of your contribution in the description of the merge request.
-
-6. Tag a Duniter reviewer so they will review your contribution. If you still have no news after several weeks, tag another reviewer or/and talk about your contribution on [the technical forum].
+1. Ensure that you respect the [commit naming conventions].
+1. Ensure that all automated tests pass with the `cargo test` command.
+1. Ensure that the code is well formated `cargo fmt` and comply with the good practices `cargo clippy`. If you have been working on tests, check everything with `cargo clippy --all --tests`.
+1. Update the documentation with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
+1. Push your branch on the gitlab and create a merge request. Briefly explain the purpose of your contribution in the description of the merge request.
+1. Tag a Duniter reviewer so they will review your contribution. If you still have no news after several weeks, tag another reviewer or/and talk about your contribution on [the technical forum].
## List of Duniter's reviewers
diff --git a/README.md b/README.md
index fbaee87c9797d1abc2c63dbe8edef02a9c991592..fb065664cd289f21c913e3168a9b8c24545f6806 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,41 @@
# Duniter v2s
-A rewriting of [Duniter](https://duniter.org) based on [Substrate](https://www.substrate.io/) framework.
-
-duniter-v2s is under active development, only a test network called "ÄžDev" is deployed.
+🆙 A rewriting of [Duniter v1](https://duniter.org) in the [Substrate](https://www.substrate.io/) framework.
+
+âš ï¸ Duniter-v2s is under active development.
+
+🚧 A test network called "ĞDev" is deployed, allowing to test wallets and indexers.
+
+<div align="center">
+ <img alt="logov2" src="https://duniter.fr/img/duniterv2.svg" width="128" height="128"/>
+</div>
+
+## Documentation TOC
+
+- [README](./README.md)
+ - [Use](#use)
+ - [Test](#test)
+ - [Contribute](#contribute)
+ - [Structure](#project-structure)
+- [docs](./docs/)
+ - [api](./docs/api/)
+ - [manual](./docs/api/manual.md)
+ - [runtime-calls](./docs/api/runtime-calls.md) the calls you can submit through the RPC API
+ - [dev](./docs/dev/)
+ - [git-conventions](./docs/dev/git-conventions.md)
+ - [launch-a-live-network](./docs/dev/launch-a-live-network.md)
+ - [setup](./docs/dev/setup.md)
+ - [verify-runtime-code](./docs/dev/verify-runtime-code.md)
+ - [weights-benchmarking](./docs/dev/weights-benchmarking.md)
+ - [test](./docs/test/)
+ - [replay-block](./docs/test/replay-block.md)
+ - [user](./docs/user/)
+ - [autocompletion](./docs/user/autocompletion.md)
+ - [build-for-arm](./docs/user/build-for-arm.md)
+ - [rpc](./docs/user/rpc.md) deploy a permanent ǦDev mirror node
+ - [smith](./docs/user/smith.md) deploy a permanent ǦDev validator node
+- [end2end-tests](./end2end-tests/) automated end to end tests written with cucumber
+- [live-tests](./live-tests/) sanity checks to test the storage of a live chain
## Use
@@ -13,27 +46,27 @@ The easiest way is to use the docker image.
Minimal command to deploy a **temporary** mirror peer:
```docker
-docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s:v0.1.0 --tmp --execution=Wasm
+docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s:v0.3.0 --tmp --execution=Wasm
```
To go further, read [How to deploy a permanent mirror node on ÄžDev network](./docs/user/rpc.md).
### Create your local blockchain
-It can be useful to deploy your local blockchain, for instance to have a controled environement
-to develop/test an application that interact with the blockchain.
+It can be useful to deploy your local blockchain, for instance to have a controlled environement
+to develop/test an application that interacts with the blockchain.
```docker
-docker run -it -p9944:9944 duniter/duniter-v2s:v0.1.0 --tmp
+docker run -it -p9944:9944 duniter/duniter-v2s:v0.3.0 --tmp
```
Or use the `docker-compose.yml` at the root of this repository.
#### Control when your local blockchain should produce blocks
-By default, your local blockchain produce a new block every 6 seconds, which is not practical in some cases.
+By default, your local blockchain produces a new block every 6 seconds, which is not practical in some cases.
-You can decide when to produce blocks with the cli option `--sealing`, , there are 2 possible modes:
+You can decide when to produce blocks with the cli option `--sealing` which has two modes:
* `--sealing=instant`: produce a block immediately upon receiving a transaction into the transaction pool
* `--sealing=manual`: produce a block upon receiving an RPC request (method `engine_createBlock`).
@@ -77,7 +110,7 @@ First, complete the [basic setup instructions](./docs/dev/setup.md).
### Build
-NOTE: You must first follow the instructions in the [Setup] section (#setup).
+NOTE: You must first follow the instructions in the [Setup](#setup-your-dev-environment) section.
Use the following command to build the node without launching it:
diff --git a/docker-compose.yml b/docker-compose.yml
index a2fce42a88afe35b94a1de19d1fc014fe77d2758..4d208572fb509749c495bbd6c06179eacbd1953e 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1,9 +1,13 @@
+# This is a minimal docker-compose.yml template for running a Duniter instance
+# For more detailed examples, look at docker/compose folder
+
version: "3.5"
services:
duniter-v2s:
container_name: duniter-v2s
- image: duniter/duniter-v2s:v0.1.0
+ # choose the version of the image here
+ image: duniter/duniter-v2s:v0.3.0
ports:
# telemetry
- 9615:9615
diff --git a/docker/compose/gdev-mirror.docker-compose.yml b/docker/compose/gdev-mirror.docker-compose.yml
index 7d00eb425e22692d329beaa1af96955a6b83c8e6..d20c95679966fec936baa169c842510d1ded46e3 100644
--- a/docker/compose/gdev-mirror.docker-compose.yml
+++ b/docker/compose/gdev-mirror.docker-compose.yml
@@ -1,8 +1,23 @@
+# This is a docker template for running a gdev mirror
+# You should write a .env file aside with the environment variables:
+#
+# --- .env ---
+# SERVER_DOMAIN=gdev.example.com
+# PEER_ID=1234XxxXXxxXxxxXxzbQqEkEpTPxD9S1PtpzkZSYoueyERA5vVtQ
+# ------------
+#
+# The peer id has to be replaced withe the output of the following command
+#
+# >>> PEER_ID >>>
+# docker run --rm -it --entrypoint duniter -v $PWD:/var/lib/duniter/ duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/node.key
+# <<<<<<<<<<<<<<<
+
+
version: "3.4"
services:
duniter-rpc:
- image: duniter/duniter-v2s:v0.2.0
+ image: duniter/duniter-v2s:v0.3.0
restart: unless-stopped
ports:
# telemetry
@@ -23,9 +38,7 @@ services:
- "/var/lib/duniter/node.key"
- "--public-addr"
# SERVER_DOMAIN should be replaced by a domain name that point on your server
- #
- # The PEER_ID should be replaced by the output of this command:
- # docker run --rm -it --entrypoint duniter -v $PWD:/var/lib/duniter/ duniter/duniter-v2s:v0.1.0 key generate-node-key --file /var/lib/duniter/node.key
+ # PEER_ID should be replaced by the output of the command given at the top of this file
- "/dns/${SERVER_DOMAIN?SERVER_DOMAIN should be set}/tcp/30333/p2p/${PEER_ID?PEER_ID should be set}"
- "--rpc-cors"
- "all"
diff --git a/docker/compose/gdev-validator.docker-compose.yml b/docker/compose/gdev-validator.docker-compose.yml
index 9ba614285ad65b6d65ff7727027144253b8c62e0..f944d09cda1838b7a0bde71024a5d98cbd83c386 100644
--- a/docker/compose/gdev-validator.docker-compose.yml
+++ b/docker/compose/gdev-validator.docker-compose.yml
@@ -2,7 +2,7 @@ version: "3.4"
services:
duniter-rpc:
- image: duniter/duniter-v2s:v0.2.0
+ image: duniter/duniter-v2s:v0.3.0
restart: unless-stopped
ports:
# telemetry
@@ -24,12 +24,12 @@ services:
# SERVER_DOMAIN should be replaced by a domain name that point on your server
#
# The PEER_ID should be replaced by the output of this command:
- # docker run --rm -it --entrypoint -v $PWD/duniter-rpc/:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.2.0 key generate-node-key --file /var/lib/duniter/node.key
+ # docker run --rm -it --entrypoint -v $PWD/duniter-rpc/:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/node.key
- "/dns/${SERVER_DOMAIN?SERVER_DOMAIN should be set}/tcp/30333/p2p/${PEER_ID?PEER_ID should be set}"
- "--rpc-cors=all"
duniter-validator:
- image: duniter/duniter-v2s:v0.2.0
+ image: duniter/duniter-v2s:v0.3.0
restart: unless-stopped
ports:
# telemetry
@@ -52,7 +52,7 @@ services:
# SERVER_DOMAIN should be replaced by a domain name that point on your server
#
# The VALIDATOR_PEER_ID should be replaced by the output of this command:
- # docker run --rm -it --entrypoint -v $PWD/duniter-rpc/:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.2.0 key generate-node-key --file /var/lib/duniter/node.key
+ # docker run --rm -it --entrypoint -v $PWD/duniter-rpc/:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/node.key
- "/dns/${SERVER_DOMAIN?SERVER_DOMAIN should be set}/tcp/30333/p2p/${VALIDATOR_PEER_ID?VALIDATOR_PEER_ID should be set}"
- "--rpc-cors=all"
- "--rpc-methods=Unsafe"
diff --git a/docs/api/manual.md b/docs/api/manual.md
index 6dd762be5483b8dc0dce5a0a9d085a468963a76c..86700e0e1e83702b08620149aa2d4fa599f6dd37 100644
--- a/docs/api/manual.md
+++ b/docs/api/manual.md
@@ -1,6 +1,6 @@
# Manual for wallet developers
-This functionnal documentation presents how wallets can interact with the blockchain.
+This functional documentation presents how wallets can interact with the blockchain.
It is intended to complete the [runtime calls documentation](./runtime-calls.md) in a runtime-specific way to fit the real needs of wallet developers.
Only ÄžDev is covered for now.
@@ -23,9 +23,9 @@ Only use `identity` pallet. The `membership` calls are disabled.
## Revoke an identity
-Revoking an identity makes it lose its membership, hence UD creation and governance rights. Orher data such as balance will remain.
+Revoking an identity makes it lose its membership, hence UD creation and governance rights. Other data such as balance will remain.
-This feature is useful in case the user has lost their private key.
+This feature is useful in case the user has lost their private key since the revocation document can be made in advance.
### Generate the revocation payload
diff --git a/docs/dev/git-conventions.md b/docs/dev/git-conventions.md
index 74c4207fd436b10d753b7010e552fea3db7e114d..c4e84b60d92e3bd5a70b87400d3940819a601f6b 100644
--- a/docs/dev/git-conventions.md
+++ b/docs/dev/git-conventions.md
@@ -15,10 +15,10 @@ The summary gives an overview of the rules described below. Reading it will help
## Naming commits
-Every commit must follow [conventional commit specification v1.0.0].
+Every commit must comply with [conventional commit specification v1.0.0].
-The commit name hase to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion.
-Among other, commit history is used in changlogs and to follow the project progress, that's why it has to be self-explanatory.
+The commit name has to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion.
+Among other, commit history is used in changlogs and to track the project progress, that's why it has to be self-explanatory.
If you have a new need, please contact the main developers to add a type together.
## Update strategy
@@ -28,18 +28,13 @@ We only use **rebases**, *merges* are strictly fordbidden !
Every time the `master` branch is updated, you must rebase each of your working branch on it. For each of them:
1. Go on your branch
-2. Run a rebase on master:
+1. Rebase on master with `git rebase master`
+1. If you see conflicts, fix them by editing the sources. Once it is done, you must:
+ 1. commit the files that were in conflict
+ 1. continue the rebase with `git rebase --continue`
+1. Keep doing until you don't have any more conflict after `git rebase --continue`.
- git rebase master
-
-3. If you see conflicts, fix them by editing the sources. Once it is done, you must:
- a. commit the files that were in conflict
- b. continue the rebase with `git rebase --continue`
- c. Do 3. again for each commit that will be in conflict.
-
-4. When you don't have any conflict anymore after `git rebase --continue`, then the rebase succeeded. Then rebase a remaning branch.
-
-To prevent accidental merge commits, we recommend that force the `--ff-only` option on the merge command:
+To prevent accidental merge commits, we recommend to force the `--ff-only` option on the merge command:
git config --global merge.ff only
@@ -58,20 +53,24 @@ any problem with your material.
After complying with the above criteria in your commits, you should check that your branch is up to date with the target branch (`master` in this example). As this branch is moving forward frequently, it is possible that new commits may have occurred while you were working on your branch (named YOUR_BRANCH, here). If this is the case or in case of doubt, to update your branch with respect to `master`, do the following:
- git checkout master # switch to master branch
- git pull # updates the remote branch based on remote
- git checkout YOU_BRANCH # switch back to your branch
- git rebase master # rebase you work on master branch
+```bash
+git checkout master # switch to master branch
+git pull # updates the remote branch based on remote
+git checkout YOU_BRANCH # switch back to your branch
+git rebase master # rebase you work on master branch
+```
In case of conflict during rebase that you can not solve, contact a lead developer telling them the hash of the commit on which YOUR_BRANCH is currently based so they can reproduce the rebase and see the conflicts. While waiting for their answer, you can cancel the rebase and work on YOUR_BRANCH without updating:
- git rebase --abort
+```
+git rebase --abort
+```
It is better to take your time before integrating a new contribution because the history of the master branch cannot be modified: it is a protected branch. Each commit on this branch remains there *ad vitam aeternam* that is why we make sure to keep a clear and understandable commit history.
## Discussion in a merge request
-On Gitlab, a discussion is opened for each merge request. It will allow you to discuss the changes you have made. Feel free to identify someone by writing @pseudo so that they are notified of your request. Don't be impatient, the review of your contribution may take more or less time depending on its content!
+On Gitlab, a discussion is opened for each merge request. It will allow you to discuss the changes you have made. Feel free to tag someone by writing @pseudo so that they are notified of your request. Don't be impatient, the review of your contribution may take more or less time depending on its content!
The general discussion is used to comment on the merge request as a whole, for example to tag a developer for a proofreading request. When it comes to discussing a specific change in the code, you should go to the "Changes" tab of the merge request and comment under the code extract involved. This makes it easier to break down the resolution of problems raised by the merge request via the "comment resolution" feature. Each segment can be marked as resolved, but only the reviewer is allowed to do so!
@@ -81,7 +80,8 @@ When you finished developing, you must compile, run linter and run all tests:
cargo fmt
cargo clippy
- cd tests && npm test
+ cargo tu
+ cargo cucumber
Then commit everything.
@@ -93,7 +93,7 @@ If you have a pile of commits, use the useful interactive rebase to clean up you
There you can rename the `wip:` commits, you can "fixup" commits that go together, you can rename and re-order commits,...
-After an interactive rebase, your local git history is different that yours in Gitlab, so you need a force push to make it to Gitlab:
+After an interactive rebase, your local git history differs from Gitlab's version, so you need a force push to make it to Gitlab:
git push -f
diff --git a/docs/dev/launch-a-live-network.md b/docs/dev/launch-a-live-network.md
index 7b3a1f7b41041f300a821ba663d79bcb6661eb3e..a5d192e525bc53bb42e21bbc3763d952417e669c 100644
--- a/docs/dev/launch-a-live-network.md
+++ b/docs/dev/launch-a-live-network.md
@@ -2,7 +2,7 @@
## 1. Choose the currency type
-Ensure that the currency type you want have the requirements.
+Ensure that the currency type you want has the requirements.
For now, only `gdev` is supported.
@@ -61,12 +61,12 @@ root of the distribution folder:
```bash
scp -r -P SSH_PORT "<path/to/dist/folder>" user@ip:/remote/dist/path
cd "<path/to/dist/folder>"
-docker-compose up -d
+docker compose up -d
```
Then, on the server:
```bash
cd "<path/to/dist/folder>"
-docker-compose up -d
+docker compose up -d
```
diff --git a/docs/dev/verify-runtime-code.md b/docs/dev/verify-runtime-code.md
index d99b7f08416e529e958a0e6abc9d56aacc0c4533..a00a8a55f41ce5b5d12f749eb56ca19293b20631 100644
--- a/docs/dev/verify-runtime-code.md
+++ b/docs/dev/verify-runtime-code.md
@@ -1,5 +1,7 @@
# Compile the runtime with srtool
+When voting for a runtime upgrade, you should check that the proposed hash actually corresponds to the published code you reviewed. Otherwise, a malicious runtime upgrade could be advertised as a legitimate one.
+
```docker
docker run \
-i \
diff --git a/docs/dev/weights-benchmarking.md b/docs/dev/weights-benchmarking.md
index 6f7f3358edfd450701334d106495822e0676bacd..8d5b699d95fe8e8a4fae0521e7bff21abac5fc23 100644
--- a/docs/dev/weights-benchmarking.md
+++ b/docs/dev/weights-benchmarking.md
@@ -6,22 +6,22 @@ complete real example.
`cargo test -p <pallet> --features runtime-benchmarks`
3. If the benchmark tests compiles and pass, compile the binary with benchmarks on your local
machine: `cargo build --release --features runtime-benchmarks`
-4. Run the benchmarks on your local machine (to test if it work mith a real runtime). The command
+4. Run the benchmarks on your local machine (to test if it work with a real runtime). The command
is: `duniter benchmark pallet --chain=CURRENCY-dev --steps=50 --repeat=20 --pallet=pallet_universal_dividend --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=.`
-5. If it work, use the generated file content to create or update the `WeightInfo` trait and the `()` dummy implementation. Then use the `WeightInfo` tarit in the real code of the pallet. See 79e0fd4bf3b0579279fc957da5e2fdfc6d8a17fa for a
+5. If it worked, use the generated file content to create or update the `WeightInfo` trait and the `()` dummy implementation. Then use the `WeightInfo` tarit in the real code of the pallet. See 79e0fd4bf3b0579279fc957da5e2fdfc6d8a17fa for a
complete real example.
6. Redo steps `3.` and `4.` on the reference machine.
7. Put the generated file on `runtime/common/src/weights` and use it in the runtimes configuration.
See cee7c3b2763ba402e807f126534d9cd39a8bd025 for a complete real example.
-Note 1: You Must replace `CURRENCY` by the currency type, or for ÄžDev use directly `--chain=dev`.
+Note 1: You *must* replace `CURRENCY` by the currency type, or for ÄžDev use directly `--chain=dev`.
-Note2. If the reference machine not support wasmtime, you should replace `--wasm-execution=compiled`
+Note 2: If the reference machine does not support wasmtime, you should replace `--wasm-execution=compiled`
by `--wasm-execution=interpreted-i-know-what-i-do`.
-## What the reference machine is?
+## What is the reference machine?
-For now (06/2022), it's a `Raspberry Pi 4 Model B - 4GB` with an SSD connected via USB3.
+For now (09/2022), it's a `Raspberry Pi 4 Model B - 4GB` with an SSD connected via USB3.
To cross-compile the benchmarks binary for armv7:
diff --git a/docs/test/replay-block.md b/docs/test/replay-block.md
index 14967ad19823b587bc340d2905687f04b0b02f06..607c555e8a0710c1b908d7b2b19c977733ddf359 100644
--- a/docs/test/replay-block.md
+++ b/docs/test/replay-block.md
@@ -1,6 +1,6 @@
# How to replay a block
-You can use `try-runtime` subcommand to replay a block against a real satte from a live network.
+You can use `try-runtime` subcommand to replay a block against a real state from a live network.
1. Checkout the git tag of the runtime version at the block you want to replay
2. Build duniter with feature `try-runtime`: `cargo build --features try-runtime`
diff --git a/docs/user/rpc.md b/docs/user/rpc.md
index 93048b5208a983c9e6e5d704f040163d008a69d1..eee02e1d23948888e4d2047d774cf85ee50a03d2 100644
--- a/docs/user/rpc.md
+++ b/docs/user/rpc.md
@@ -4,23 +4,27 @@
### Duniter part
-- Add this docker-compose on your server :
+- Add this docker-compose template on your server:
[docker/compose/gdev-rpc.docker-compose.yml](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/docker/compose/gdev-mirror.docker-compose.yml)
- Rename the file : `mv gdev-mirror.docker-compose.yml docker-compose.yml`
- In the same folder, create a `.env` file that defime environment variables `SERVER_DOMAIN` and `PEER_ID`:
-```
+```bash
SERVER_DOMAIN=YOUR_DOMAIN
PEER_ID=YOUR_PEER_ID
```
-Your `PEER_ID` shoud be generated with this command:Â `docker run --rm -it --entrypoint duniter -v $PWD:/var/lib/duniter/ duniter/duniter-v2s:v0.2.0 key generate-node-key --file /var/lib/duniter/node.key`
+Your `PEER_ID` shoud be generated with this command:Â
+```bash
+docker run --rm -it --entrypoint duniter -v $PWD:/var/lib/duniter/ duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/node.key
+```
- If you have write access errors run in docker-compose.yml folder : `chmod o+rwX -R .`
-- `docker-compose up -d` to start your node
+- Do `docker compose up -d` to start your node
### Reverse-proxy part (with Nginx)
-In `/etc/nginx/sites-enabled/gdev.YOUR_DOMAIN` put (you can probably do simpler) :
-```
+In `/etc/nginx/sites-enabled/gdev.YOUR_DOMAIN` put (you can probably do simpler):
+
+```nginx
server {
server_name gdev.YOUR_DOMAIN.fr;
diff --git a/docs/user/smith.md b/docs/user/smith.md
index 915bb52b35e7fe3b1dd4dec8d1956953484d8892..941a2fa1a59979fd8231f1738f1cdc4aad9e1a91 100644
--- a/docs/user/smith.md
+++ b/docs/user/smith.md
@@ -8,16 +8,17 @@
[docker/compose/gdev-validator.docker-compose.yml](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/docker/compose/gdev-validator.docker-compose.yml)
- Create a `.env` file that define environment variables `SERVER_DOMAIN`, `PEER_ID` and `VALIDATOR_PEER_ID`:
- `SERVER_DOMAIN`:Â a domain name that point on your server
- - `PEER_ID`: Your rpc node peer id, shoud be generated with this command:Â `docker run --rm -it --entrypoint -v $PWD:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.2.0 key generate-node-key --file /var/lib/duniter/rpc-node.key`
- - `VALIDATOR_PEER_ID`: Your validator node peer id, shoud be generated with this command:Â `docker run --rm -it --entrypoint -v $PWD:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.2.0 key generate-node-key --file /var/lib/duniter/validator-node.key`
+ - `PEER_ID`: Your rpc node peer id, shoud be generated with this command:Â `docker run --rm -it --entrypoint -v $PWD:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/rpc-node.key`
+ - `VALIDATOR_PEER_ID`: Your validator node peer id, shoud be generated with this command:Â `docker run --rm -it --entrypoint -v $PWD:/var/lib/duniter/ duniter duniter/duniter-v2s:v0.3.0 key generate-node-key --file /var/lib/duniter/validator-node.key`
Note: duniter-rpc PEER_ID and duniter-validator PEER_ID isn't the same.
- If you have write access errors run in docker-compose.yml folder : `chmod o+rwX -R .`
-- `docker-compose up -d` to start your node
+- `docker compose up -d` to start your node
### Reverse-proxy part (with Nginx)
-In `/etc/nginx/sites-enabled/gdev.YOUR_DOMAIN` put (you can probably do simpler) :
-```
+In `/etc/nginx/sites-enabled/gdev.YOUR_DOMAIN` put (you can probably do simpler):
+
+```nginx
server {
server_name gdev.YOUR_DOMAIN.fr;
@@ -75,7 +76,7 @@ Your node is now online as a rpc node. It's fully capable for wallet use.
- Send the query
- Await smith certification : developer > extrinsics > CERTIFIER_SMITH_ACCOUNT > smithCert > addCert(receiver)
-When you have at least 3 certifications, your'in !
+When you have at least 3 certifications, your'in!
## Validate blocks (blacksmith work)
diff --git a/end2end-tests/README.md b/end2end-tests/README.md
index 6bea5535161d2e486fc8cae70415ae783728139b..b5f21c0c2013e983c6566a804a558899a1735984 100644
--- a/end2end-tests/README.md
+++ b/end2end-tests/README.md
@@ -1,6 +1,6 @@
# Duniter-v2s end2end tests
-## Cucumber functionnal tests
+## Cucumber functional tests
We use [cucumber] to be able to describe test scenarios in human language.
@@ -81,14 +81,22 @@ List of possible actions:
### Test users
-6 test users are provided:
+8 test users are provided derived from the same [dev mnemonic](https://docs.substrate.io/v3/getting-started/glossary/#dev-phrase)
-- alice
-- bob
-- charlie
-- dave
-- eve
-- ferdie
+```
+bottom drive obey lake curtain smoke basket hold race lonely fit walk
+```
+
+with the derivation path `//Alice`, `//Bob`...
+
+- alice `5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY`
+- bob `5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty`
+- charlie `5FLSigC9HGRKVhB9FiEo4Y3koPsNmBmLJbpXg2mp1hXcS59Y`
+- dave `5DAAnrj7VHTznn2AWBemMuyBwZWs6FNFjdyVXUeYum3PTXFy`
+- eve `5HGjWAeFDfFCWPsjFQdVV2Msvz2XtMktvgocEZcCj68kUMaw`
+- ferdie `5CiPPseXPECbkjWCa6MnjNokrgYjMqmKndv2rSnekmSK2DjL`
+- one `5Fxune7f71ZbpP2FoY3mhYcmM596Erhv1gRue4nsPwkxMR4n`
+- two `5CUjxa4wVKMj3FqKdqAUf7zcEMr4MYAjXeWmUf44B41neLmJ`
### Currency amounts
diff --git a/scripts/create-live-network.sh b/scripts/create-live-network.sh
index 87e2664445087839904ca15bbd59edf9b65a9600..b58ed65b43120d60447972e28e6f94fa0d48145b 100755
--- a/scripts/create-live-network.sh
+++ b/scripts/create-live-network.sh
@@ -78,4 +78,4 @@ docker cp duniter-tmp:/var/lib/duniter/chains/${CURRENCY}_local/keystore $WORK_D
# Launch the network
echo "compose ready in '$WORK_DIR'"
cd $WORK_DIR
-#docker-compose up -d
+#docker compose up -d
diff --git a/scripts/docker.sh b/scripts/docker.sh
index 4570ac2c08f832056292bcceb7ae03ccadfcae93..2df8abf2b835b62b5b04564e71cf97621bf7c58a 100755
--- a/scripts/docker.sh
+++ b/scripts/docker.sh
@@ -10,5 +10,5 @@ mkdir -p build
cp target/release/duniter build/duniter
docker build -t "duniter/duniter-v2s:local" -f ".maintain/local-docker-test-network/duniter.Dockerfile" .
-#docker-compose down --remove-orphans
-#docker-compose run --rm --service-ports dev $@
+#docker compose down --remove-orphans
+#docker compose run --rm --service-ports dev $@