You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/prepare_beta_release.md
+17-10Lines changed: 17 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,15 +21,21 @@ All items below are to be completed by the owner of the given release.
21
21
-[ ] Assign release candidate tag to the release branch HEAD (e.g. `v0.X.0-beta-rc.0`, `v0.X.0-beta-rc.1`, ... `v0.X.0-beta-rc.N`).
22
22
-[ ] Generate and edit release notes in CHANGELOG.md.
23
23
24
-
-[ ]**Waku test and fleets validation**
25
-
-[ ] Ensure all the unit tests (specifically logos-delivery-js tests) are green against the release candidate.
26
-
-[ ] Deploy the release candidate to `waku.test` only through [deploy-waku-test job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
27
-
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to master.
28
-
- Verify the deployed version at https://fleets.waku.org/.
29
-
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/logos-delivery/artifacts-tab).
30
-
-[ ] Analyze Kibana logs from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
31
-
- Most relevant logs are `(fleet: "waku.test" AND message: "SIGSEGV")`.
32
-
-[ ] Enable again the `waku.test` fleet to resume auto-deployment of the latest `master` commit.
24
+
-[ ]**Validation of release candidate**
25
+
-[ ]**Automated testing**
26
+
-[ ] Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
27
+
-[ ]**Waku fleet testing**
28
+
-[ ] Deploy the release candidate to `waku.test` through [deploy-waku-test job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
29
+
- After completion, disable fleet so that daily CI does not override your release candidate.
30
+
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
31
+
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
32
+
-[ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
33
+
- Set time range to "Last 30 days" (or since last release).
34
+
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
35
+
- Document any crashes or errors found.
36
+
-[ ] If `waku.test` validation is successful, deploy to `waku.sandbox` using the [deploy-waku-sandbox job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/).
37
+
-[ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
38
+
-[ ] Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
33
39
34
40
-[ ]**Proceed with release**
35
41
@@ -53,4 +59,5 @@ All items below are to be completed by the owner of the given release.
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/prepare_full_release.md
+31-24Lines changed: 31 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,33 +24,39 @@ All items below are to be completed by the owner of the given release.
24
24
-[ ]**Validation of release candidate**
25
25
26
26
-[ ]**Automated testing**
27
-
-[ ] Ensure all the unit tests (specifically logos-delivery-js tests) are green against the release candidate.
28
-
-[ ] Ask Vac-QA and Vac-DST to perform the available tests against the release candidate.
29
-
-[ ] Vac-DST (an additional report is needed; see [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f))
27
+
-[ ] Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
30
28
31
29
-[ ]**Waku fleet testing**
32
-
-[ ] Deploy the release candidate to `waku.test`and `waku.sandbox` fleets.
33
-
- Start the [deployment job](https://ci.infra.status.im/job/nim-waku/)for both fleets and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
34
-
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/)so that its version is not updated on every merge to `master`.
35
-
- Verify the deployed version at https://fleets.waku.org/.
30
+
-[ ] Deploy the release candidate to `waku.test`fleet.
31
+
- Start the [deployment job](https://ci.infra.status.im/job/nim-waku/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
32
+
- After completion, disable fleet so that daily CI does not override your release candidate.
33
+
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
36
34
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
37
-
-[ ] Search _Kibana_ logs from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test` and `waku.sandbox`.
38
-
- Most relevant logs are `(fleet: "waku.test" AND message: "SIGSEGV")` OR `(fleet: "waku.sandbox" AND message: "SIGSEGV")`.
39
-
-[ ] Enable again the `waku.test` fleet to resume auto-deployment of the latest `master` commit.
40
-
41
-
-[ ]**Status fleet testing**
42
-
-[ ] Deploy release candidate to `status.staging`
43
-
-[ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
44
-
-[ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
45
-
- 1:1 Chats with each other
46
-
- Send and receive messages in a community
47
-
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
48
-
-[ ] Perform checks based on _end user impact_
49
-
-[ ] Inform other (Waku and Status) CCs to point their instances to `status.staging` for a few days. Ping Status colleagues on their Discord server or in the [Status community](https://status.app/c/G3kAAMSQtb05kog3aGbr3kiaxN4tF5xy4BAGEkkLwILk2z3GcoYlm5hSJXGn7J3laft-tnTwDWmYJ18dP_3bgX96dqr_8E3qKAvxDf3NrrCMUBp4R9EYkQez9XSM4486mXoC3mIln2zc-TNdvjdfL9eHVZ-mGgs=#zQ3shZeEJqTC1xhGUjxuS4rtHSrhJ8vUYp64v6qWkLpvdy9L9) (this is not a blocking point.)
50
-
-[ ] Ask Status-QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested
51
-
-[ ] Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`
52
-
-[ ] Get other CCs' sign-off: they should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
53
-
-[ ]**Get Status-QA sign-off**, ensuring that the `status.test` update will not disturb ongoing activities.
35
+
-[ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
36
+
- Set time range to "Last 30 days" (or since last release).
37
+
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
38
+
- Document any crashes or errors found.
39
+
-[ ] If `waku.test` validation is successful, deploy to `waku.sandbox` using the same [deployment job](https://ci.infra.status.im/job/nim-waku/).
40
+
-[ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
41
+
-[ ] Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
42
+
43
+
-[ ]**QA and DST testing**
44
+
-[ ] Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
45
+
-[ ] Vac-DST: An additional report is needed ([see this example](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f)). Inform DST team about what are the expectations for this rc. For example, if we expect higher or lower bandwidth consumption.
46
+
47
+
-[ ]**Status fleet testing**
48
+
-[ ] Deploy release candidate to `status.staging`
49
+
-[ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
50
+
-[ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
51
+
- 1:1 Chats with each other
52
+
- Send and receive messages in a community
53
+
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
54
+
-[ ] Perform checks based on _end user impact_
55
+
-[ ] Inform other (Waku and Status) CCs to point their instances to `status.staging` for a few days. Ping Status colleagues on their Discord server or in the [Status community](https://status.app/c/G3kAAMSQtb05kog3aGbr3kiaxN4tF5xy4BAGEkkLwILk2z3GcoYlm5hSJXGn7J3laft-tnTwDWmYJ18dP_3bgX96dqr_8E3qKAvxDf3NrrCMUBp4R9EYkQez9XSM4486mXoC3mIln2zc-TNdvjdfL9eHVZ-mGgs=#zQ3shZeEJqTC1xhGUjxuS4rtHSrhJ8vUYp64v6qWkLpvdy9L9) (this is not a blocking point.)
56
+
-[ ] Ask Status-QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested
57
+
-[ ] Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`
58
+
-[ ] Get other CCs' sign-off: they should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
59
+
-[ ]**Get Status-QA sign-off**, ensuring that the `status.test` update will not disturb ongoing activities.
54
60
55
61
-[ ]**Proceed with release**
56
62
@@ -74,3 +80,4 @@ All items below are to be completed by the owner of the given release.
@@ -70,20 +70,26 @@ For more context, see https://trunkbaseddevelopment.com/branch-for-release/
70
70
71
71
6a. **Automated testing**
72
72
- Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
73
-
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
74
-
75
-
> We need an additional report like [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f) specifically from the DST team.
76
73
77
74
6b. **Waku fleet testing**
78
-
- Start job on `waku.sandbox` and `waku.test` [Deployment job](https://ci.infra.status.im/job/nim-waku/), wait for completion of the job. If it fails, then debug it.
79
-
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to `master`.
80
-
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate version.
75
+
- Start job on `waku.test` [Deployment job](https://ci.infra.status.im/job/nim-waku/), wait for completion of the job. If it fails, then debug it.
76
+
- After completion, disable fleet so that daily ci not override your release candidate.
77
+
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
81
78
- Check if the image is created at [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
82
-
- Search _Kibana_ logs from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test` and `waku.sandbox`.
83
-
- Most relevant logs are `(fleet: "waku.test" AND message: "SIGSEGV")` OR `(fleet: "waku.sandbox" AND message: "SIGSEGV")`.
79
+
- Search [Kibana logs](https://kibana.infra.status.im/app/discover) from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test`.
80
+
- Set time range to "Last 30 days" (or since last release).
81
+
- Most relevant search query: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
82
+
- Document any crashes or errors found.
83
+
- If `waku.test` validation is successful, deploy to `waku.sandbox` using the same [Deployment job](https://ci.infra.status.im/job/nim-waku/).
84
+
- Search [Kibana logs](https://kibana.infra.status.im/app/discover) for `waku.sandbox`: `(fleet: "waku.sandbox" AND message: "SIGSEGV")`, `(fleet: "waku.sandbox" AND message: "exception")`, `(fleet: "waku.sandbox" AND message: "error")`. most probably if there are no crashes or errors in `waku.test`, there will be no crashes or errors in `waku.sandbox`.
84
85
- Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
85
86
86
-
6c. **Status fleet testing**
87
+
6c. **QA and DST testing**
88
+
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
89
+
90
+
> We need an additional report like [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f) specifically from the DST team. Inform DST team about what are the expectations for this rc. For example, if we expect higher or lower bandwidth consumption.
91
+
92
+
6d. **Status fleet testing**
87
93
- Deploy release candidate to `status.staging`
88
94
- Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
89
95
- Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
@@ -120,10 +126,10 @@ We also need to merge the release branch back into master as a final step.
120
126
2. Deploy the release image to [Dockerhub](https://hub.docker.com/r/wakuorg/nwaku) by triggering [the manual Jenkins deployment job](https://ci.infra.status.im/job/nim-waku/job/docker-manual/).
0 commit comments