mirror of
https://github.com/logos-messaging/logos-messaging-nim.git
synced 2026-06-27 11:59:26 +00:00
chore: simplify release process — merge deploy into prepare_release (#3964)
Co-authored-by: Igor Sirotin <sirotin@status.im>
This commit is contained in:
parent
a73035e28d
commit
319c0c68fe
55
.github/ISSUE_TEMPLATE/deploy_release.md
vendored
55
.github/ISSUE_TEMPLATE/deploy_release.md
vendored
@ -1,55 +0,0 @@
|
||||
---
|
||||
name: Deploy Release
|
||||
about: Execute tasks for deploying a new version in a fleet
|
||||
title: 'Deploy release vX.X.X in logos.test and/or status.prod fleet'
|
||||
labels: deploy-release
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Add appropriate release number and adjust the target fleet in the title!
|
||||
-->
|
||||
|
||||
### Link to the Release PR
|
||||
|
||||
<!--
|
||||
Kindly add a link to the release PR where we have a sign-off from QA. At this time, that release PR should be already merged.
|
||||
-->
|
||||
|
||||
### Items to complete, in order
|
||||
|
||||
<!--
|
||||
You can release into either logos.test, status.prod, or both. Both cases require coordination with Infra Team.
|
||||
logos.test must be considered a prod fleet as it is used by external parties.
|
||||
For both status.prod it is crucial to coordinate such deployment with Status Team.
|
||||
The following points should be followed in order.
|
||||
-->
|
||||
|
||||
- [ ] Receive sign-off from DST.
|
||||
- [ ] Inform DST team about what are the expectations for this release. For example, if we expect higher, same or lower bandwidth consumption. Or a new protocol appears, etc.
|
||||
- [ ] Ask DST to add a comment approving this deployment and add a link to the analysis report.
|
||||
|
||||
- [ ] Deploy to logos.test
|
||||
- [ ] Coordinate with Infra Team about possible changes in CI behavior
|
||||
- [ ] Update logos.test with the corresponding deployment job in [Jenkins](https://ci.infra.status.im/) (ask the Infra Team if you don't have access or can't find the job).
|
||||
|
||||
- [ ] Deploy to status.prod
|
||||
- [ ] Coordinate with Infra Team about possible changes in CI behavior
|
||||
- [ ] Ask Status admin to add a comment approving that this deployment to happen now.
|
||||
- [ ] Update status.prod with [this deployment job](https://ci.infra.status.im/job/nim-waku/job/deploy-status-prod/).
|
||||
|
||||
- [ ] Update infra config
|
||||
- [ ] Submit PRs into infra repos to adjust deprecated or changed arguments (review CHANGELOG.md for that release). And confirm the fleet can run after that. This requires coordination with infra team.
|
||||
|
||||
### Reference Links
|
||||
|
||||
- [Release process](https://github.com/logos-messaging/logos-delivery/blob/master/docs/contributors/release-process.md)
|
||||
- [Release notes](https://github.com/logos-messaging/logos-delivery/blob/master/CHANGELOG.md)
|
||||
- [Infra-role-logos-node](https://github.com/status-im/infra-role-logos-node)
|
||||
- [Infra-logos](https://github.com/status-im/infra-logos)
|
||||
- [Infra-Status](https://github.com/status-im/infra-status)
|
||||
- [Jenkins](https://ci.infra.status.im/)
|
||||
- [Fleets](https://fleets.logos.co/)
|
||||
- [Harbor](https://harbor.status.im/harbor/projects/32/repositories/logos-node/artifacts-tab)
|
||||
- [Kibana](https://kibana.infra.status.im/app/)
|
||||
106
.github/ISSUE_TEMPLATE/prepare_release.md
vendored
106
.github/ISSUE_TEMPLATE/prepare_release.md
vendored
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: Prepare Release
|
||||
about: Execute tasks for the creation and publishing of a new full release
|
||||
about: Execute tasks for the creation, validation, deployment and publishing of a new full release
|
||||
title: 'Prepare release 0.0.0'
|
||||
labels: full-release
|
||||
assignees: ''
|
||||
@ -8,64 +8,81 @@ assignees: ''
|
||||
---
|
||||
|
||||
<!--
|
||||
Add appropriate release number to title!
|
||||
|
||||
For detailed info on the release process refer to https://github.com/logos-messaging/logos-delivery/blob/master/docs/contributors/release-process.md
|
||||
Add appropriate release number to title
|
||||
-->
|
||||
|
||||
### Items to complete
|
||||
### Items to complete, in order
|
||||
|
||||
All items below are to be completed by the owner of the given release.
|
||||
#### Initial validation
|
||||
- [ ] Confirm waku.test has been running with new commits on each merge into master (see Grafana boards.)
|
||||
- [ ] Search [Kibana logs](https://kibana.infra.status.im/app/discover) since the last release for crashes or errors in waku.test that we didn't detect in CI.
|
||||
- Most relevant search queries: `(fleet: "waku.test" AND message: "SIGSEGV")`, `(fleet: "waku.test" AND message: "exception")`, `(fleet: "waku.test" AND message: "error")`.
|
||||
- Detect unexpected reboots.
|
||||
- Document any crashes or errors found and fix them before proceeding.
|
||||
|
||||
- [ ] Create release branch with major and minor only ( e.g. release/v0.X ) if it doesn't exist.
|
||||
- [ ] Update the `version` field in `logos_delivery.nimble` to match the release version (e.g. `version = "0.X.0"`) **and merge it before assigning any tag** - the `release-assets` workflow gates artifact build/upload.
|
||||
### Create the release candidate
|
||||
|
||||
- [ ] Create release branch with major and minor only ( e.g. release/v0.X ).
|
||||
- [ ] In release branch, update the `version` field in `logos_delivery.nimble` to match the release version (e.g. `version = "0.X.0"`).
|
||||
- [ ] Assign release candidate tag to the release branch HEAD (e.g. `v0.X.0-rc.0`, `v0.X.0-rc.1`, ... `v0.X.0-rc.N`).
|
||||
- [ ] Generate and edit release notes in CHANGELOG.md.
|
||||
|
||||
- [ ] **Validation of release candidate**
|
||||
#### Validate the release candidate
|
||||
|
||||
- [ ] **Automated testing**
|
||||
- [ ] Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
|
||||
- [ ] 1. Essential test
|
||||
- [ ] Ensure all unit tests are green
|
||||
- [ ] Get interop tests results from QA
|
||||
|
||||
- [ ] **QA testing**
|
||||
- [ ] Ask QA to run their available tests against the release candidate.
|
||||
|
||||
- [ ] **Logos fleet testing**
|
||||
- [ ] Deploy the release candidate to `logos.dev` fleet.
|
||||
- [ ] 2. Fleet validation (pre-requisite: 1. Can be done in parallel with 3.)
|
||||
- [ ] Deploy the release candidate to the waku.test fleet.
|
||||
- Start the deployment job in [Jenkins](https://ci.infra.status.im/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
|
||||
- After completion, disable fleet so that daily CI does not override your release candidate.
|
||||
- Verify at https://fleets.logos.co/ that the fleet is locked to the release candidate image.
|
||||
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/32/repositories/logos-node/artifacts-tab).
|
||||
- [ ] 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 `logos.dev`.
|
||||
- Set time range to "Last 30 days" (or since last release).
|
||||
- Most relevant search query: `(fleet: "logos.dev" AND message: "SIGSEGV")`, `(fleet: "logos.dev" AND message: "exception")`, `(fleet: "logos.dev" AND message: "error")`.
|
||||
- Document any crashes or errors found.
|
||||
- [ ] Ask QA to perform tests against `logos.dev`, if any. Then, after that, review Kibana for possible issues or unexpected restart.
|
||||
- [ ] Enable the `logos.dev` fleet again to resume auto-deployment of the latest `master` commit.
|
||||
- After completion, disable the fleet so that daily CI does not override your release candidate.
|
||||
- Verify at https://fleets.logos.co/ that the fleet is locked to the release candidate image.
|
||||
|
||||
- [ ] Ask QA to run tests against waku.test and attach a screenshot as evidence.
|
||||
- [ ] Re-enable the waku.test fleet to resume auto-deployment of the latest master commit.
|
||||
<!-- In the future, automate `waku.test` crash detection so `master` stays continuously green and we can cut a release easier. -->
|
||||
|
||||
- [ ] **Status testing**
|
||||
- [ ] Get QA approval to deploy a new version in `status.staging`.
|
||||
- [ ] Deploy release candidate to `status.staging`.
|
||||
- [ ] Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
|
||||
- [ ] Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client mode.
|
||||
- 1:1 Chats with each other.
|
||||
- Send and receive messages in a community.
|
||||
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store.
|
||||
- [ ] Perform checks based on _end user impact_
|
||||
- [ ] 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.)
|
||||
- [ ] Ask QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested
|
||||
- [ ] Ask QA or infra to run the automated Status e2e tests against `status.staging`
|
||||
- [ ] 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.
|
||||
- [ ] 3. DST sign-off (pre-requisite: 1)
|
||||
- [ ] Inform the DST team about the expectations for this release. For example, if we expect higher, same or lower bandwidth consumption, or a new protocol appears, etc.
|
||||
- [ ] Ask DST to add a comment approving this release and add a summary analysis report.
|
||||
|
||||
- [ ] **Proceed with release**
|
||||
- [ ] 4. Status testing (pre-requisite: 1, 2, 3)
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-go-bindings](https://github.com/logos-messaging/logos-delivery-go-bindings) and make sure all tests work.
|
||||
- [ ] Submit a PR on [status-go](https://github.com/status-im/status-go/blob/1f9061064587e1167e32d965d5a6f2b745324d5e/tests-functional/docker-compose.waku.yml#L3) bumping logos-delivery to this release candidate.
|
||||
- [ ] Submit a PR on [status-app](https://github.com/status-im/status-app/blob/3639e28374ca3c2158ac2dac6af35dbce439b10a/docker-compose.waku.yml#L3) bumping logos-delivery to this release candidate.
|
||||
- [ ] Both PRs must be merged before the release is considered created.
|
||||
- [ ] Deploy the release candidate in status.staging. That may alert about needed infra changes.
|
||||
|
||||
- [ ] Assign a final release tag (`v0.X.0`) to the same commit that contains the validated release-candidate tag (e.g. `git tag -as v0.X.0 -m "final release."`).
|
||||
- [ ] 5. Submit a PR against release/v0.X with CHANGELOG.md updates (pre-requisite: all previous.)
|
||||
|
||||
#### Complete the release
|
||||
- [ ] Assign a final release tag (`v0.X.0`) to the same commit that contains the latest release-candidate tag (e.g. `git tag -as v0.X.0 -m "final release."`).
|
||||
- [ ] Update [logos-delivery-compose](https://github.com/logos-messaging/logos-delivery-compose) and [logos-delivery-simulator](https://github.com/logos-messaging/logos-delivery-simulator) according to the new release.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-rust-bindings](https://github.com/logos-messaging/logos-delivery-rust-bindings) and make sure all examples and tests work.
|
||||
- [ ] Bump logos-delivery dependency in [logos-delivery-go-bindings](https://github.com/logos-messaging/logos-delivery-go-bindings) and make sure all tests work.
|
||||
- [ ] Create GitHub release (https://github.com/logos-messaging/logos-delivery/releases).
|
||||
- [ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
|
||||
- [ ] Create a deployment issue with the recently created release.
|
||||
- [ ] Merge release branch into master
|
||||
- [ ] Create a temporary branch from the release branch. This is needed in case we need to rebase that branch without impacting the release branch. Notice that the release branch should live forever.
|
||||
- [ ] Submit a PR from temporary branch to master. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
|
||||
- [ ] Adjust the status-go and status-app `docker-compose.waku.yml` files (the ones bumped above) so they use the final tag instead of the release candidate one.
|
||||
|
||||
#### Deployment
|
||||
- [ ] Deploy to waku.sandbox
|
||||
- [ ] Confirm the release candidate ran properly in waku.test with the current infra config.
|
||||
- [ ] If it did NOT (e.g. CLI params changed): submit PRs to the infra repos adjusting the deprecated or changed arguments (review CHANGELOG.md for that release), add links to them, and wait until they are merged. Infra changes are deployed by the infra team, so this requires coordination with them.
|
||||
- [ ] If it ran fine with the current config, no infra PR is needed.
|
||||
- [ ] Deploy:
|
||||
- [ ] Coordinate with the Infra Team about the deployment timing.
|
||||
- [ ] Update waku.sandbox with [this deployment job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-sandbox/).
|
||||
- [ ] Confirm the fleet runs properly after the deployment.
|
||||
- [ ] Deploy to status.prod
|
||||
- [ ] Confirm the release candidate ran properly in status.staging with the current infra config.
|
||||
- [ ] If it did NOT (e.g. CLI params changed): submit PRs to the infra repos adjusting the deprecated or changed arguments (review CHANGELOG.md for that release), add links to them, and wait until they are merged. Infra changes are deployed by the infra team, so this requires coordination with them.
|
||||
- [ ] If it ran fine with the current config, no infra PR is needed.
|
||||
- [ ] Deploy:
|
||||
- [ ] Ask the Status admin to add a comment approving that this deployment happen now.
|
||||
- [ ] Update status.prod with [this deployment job](https://ci.infra.status.im/job/nim-waku/job/deploy-status-prod/).
|
||||
- [ ] Confirm the fleet runs properly after the deployment.
|
||||
|
||||
|
||||
### Links
|
||||
|
||||
@ -73,6 +90,7 @@ All items below are to be completed by the owner of the given release.
|
||||
- [Release notes](https://github.com/logos-messaging/logos-delivery/blob/master/CHANGELOG.md)
|
||||
- [Fleet ownership](https://www.notion.so/Fleet-Ownership-7532aad8896d46599abac3c274189741?pvs=4#d2d2f0fe4b3c429fbd860a1d64f89a64)
|
||||
- [Infra-logos](https://github.com/status-im/infra-logos)
|
||||
- [Infra-Status](https://github.com/status-im/infra-status)
|
||||
- [Jenkins](https://ci.infra.status.im/)
|
||||
- [Fleets](https://fleets.logos.co/)
|
||||
- [Harbor](https://harbor.status.im/harbor/projects/32/repositories/logos-node/artifacts-tab)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user