mirror of https://github.com/logos-co/roadmap.git
Nwaku release process (#90)
* migrate nwaku release process doc from notion * migrate test nwaku on status doc from notion * edit format
This commit is contained in:
chair
GitHub
parent
cc7b8baa14
commit
0fa81be8aa
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: nwaku Release Process
|
||||
tags:
|
||||
- Waku
|
||||
- collaboration
|
||||
- nwaku
|
||||
date: 2024-07-22
|
||||
lastmod: 2024-07-22
|
||||
---
|
||||
|
||||
## Testing week
|
||||
|
||||
On each release, we establish a testing period of one week, when we lock the `waku.test` fleet so that it only runs the target version. During that period, we need to continuously stress that fleet from the sandbox machine, for example.
|
||||
|
||||
It is important to make sure the `waku-simulator` works as expected and the nodes can establish connections among themselves.
|
||||
|
||||
During that week, the release owner needs to check the *Kibana* logs from the previous month (since the last release was deployed) looking for possible crashes or errors in `waku.test` & `waku.sandbox`. These are the most relevant logs to check:
|
||||
|
||||
- `(fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"`
|
||||
|
||||
Make sure that Status client works properly when connected to a fleet running on the release candidate version. For it, please follow its corresponding [guide](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425?pvs=21).
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
title: Test nwaku on Status
|
||||
tags:
|
||||
- Waku
|
||||
- Status
|
||||
- collaboration
|
||||
- nwaku
|
||||
date: 2024-07-22
|
||||
lastmod: 2024-07-22
|
||||
---
|
||||
|
||||
This document is based on the following [recorded session](https://drive.google.com/file/d/16ZJB5n2aazf9LfGZPKHPTGJy9zZJ6nIH/view)
|
||||
|
||||
In order to test Nwaku on Status, you need to first deploy your release candidate to the `shards.staging` fleet. You will also need to build status-desktop by following the instructions [here](https://www.notion.so/Building-ca1db4fb3baf4f15bab8da717832b743?pvs=21).
|
||||
|
||||
Once we are able to run status-desktop locally, run
|
||||
|
||||
```bash
|
||||
make run ARGS="--enable-fleet-selection --datadir=./datadir1"
|
||||
```
|
||||
|
||||
This will open Status Desktop. Create a new account, and once logged in go to `Settings->Advanced->Fleet` and select `shards.staging`
|
||||
|
||||
|
||||
|
||||
After selecting the fleet, Status Desktop will close and you will need to run again
|
||||
|
||||
```bash
|
||||
make run ARGS="--enable-fleet-selection --datadir=./datadir1"
|
||||
```
|
||||
|
||||
Log in with the password you set previously, and check that`shards.staging` is configured
|
||||
|
||||
|
||||
|
||||
In the Advanced section again, please enable the following options:
|
||||
|
||||
- Full developer mode
|
||||
- Debug
|
||||
- Node Management
|
||||
- Enable creation of sharded communities
|
||||
- Enable Community Creation
|
||||
|
||||
Some of these options might also close your Status Desktop window. If so, run again Status Desktop with the same command as before and check that all the above configurations are enabled.
|
||||
|
||||
Now, open a new terminal and run a new instance of Status Desktop using a different directory for its database. For example
|
||||
|
||||
```bash
|
||||
make run ARGS="--enable-fleet-selection --datadir=./datadir2"
|
||||
```
|
||||
|
||||
Follow the same steps as with the other Status Desktop instance, only changing the `datadir` flag
|
||||
|
||||
With the previous step completed, enter the `Node Management` section and check that both instances are connected to peers
|
||||
|
||||
|
||||
|
||||
In one of the accounts, copy the link to its profile
|
||||
|
||||
|
||||
|
||||
And then, in the other account, send it a contact request
|
||||
|
||||
|
||||
|
||||
Make sure you get a notification for it in your other window and accept the contact request
|
||||
|
||||
|
||||
|
||||
Chat between both accounts and check that messages get delivered properly
|
||||
|
||||
|
||||
|
||||
Finally, test that the Store nodes work properly.
|
||||
|
||||
For it, close one of the windows and from the open window send messages to it.
|
||||
|
||||
Re-run the Status Desktop instance you just closed and check that you receive the messages sent to you when you were offline.
|
||||
|
||||
Some extra operations that we can run to double check everything is ok are:
|
||||
|
||||
- In `Node Management` run the RPC method `{"method":"settings_nodeConfig"}` and check in the output that you are connected to the right fleet
|
||||
- Similarly, you can run the RPC method `{"method":"wakuext_peers"}` to get the list of peers
|
||||
- Check in `Settings→Advanced→History nodes` the history nodes we are connected to
|
||||
|
||||
To do: define how to test Status Communities
|
||||
Loading…
Reference in New Issue