logos-messaging/logos-messaging-nim
1
0
Fork 0
mirror of https://github.com/logos-messaging/logos-messaging-nim.git synced 2026-05-21 01:39:39 +00:00
Code Issues Packages Projects Releases Wiki Activity
logos-messaging-nim/.github/ISSUE_TEMPLATE/prepare_release.md
Igor Sirotin c6e448a0ba
fix: real getNodeInfo Version in Nix/lgpm builds (#3889) 
* fix(node-info): real Version + new Commit in Nix/lgpm builds

getNodeInfo Version returned "n/a" on Nix-built libs (and lgpm
releases built from the flake) because nix/default.nix never passed
-d:git_version. A flake sandbox has no .git, so git describe is
impossible; derive the semver from waku.nimble's version field plus
the flake short commit, and expose the full commit SHA via a new
Commit node info id.

- waku_state_info: add Commit to NodeInfoId + dispatch git_commit
- waku_node: add git_commit {.strdefine.} (default "n/a")
- node start logs ("Starting Waku node" / "Running nwaku node") now
  print commit = git_commit alongside version
- Makefile: inject -d:git_commit (full SHA), mirrors docker label
- nix/default.nix: accept gitVersion/gitCommit, pass as nim defines
- flake.nix: gitVersion = <nimble version>-g<shortRev>, gitCommit = rev
- CI version-check (PR only): ancestor-aware `git describe --tags
  --abbrev=0` vs PR HEAD, base-version compare, so waku.nimble is kept
  current early and a new tag never breaks in-flight PRs
- release-assets.yml: gate build/upload on a verify-version job
  asserting tag base == waku.nimble (RC tags allowed), so a mismatched
  tag publishes no artifacts
- docs: prepare_release.md explains the bump-before-tag requirement

Refs: status-im/infra-logos#4
Closes: logos-messaging/logos-delivery#3884

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: simplify

* chore: update version in waku.nimble

* fix(node-info): remove Commit node info field

Drop the newly added Commit (full SHA) node info id and its
git_commit compile-time define plumbing across Makefile, flake.nix
and nix/default.nix; revert the start/run log lines to version only.
The PR now solely fixes the getNodeInfo Version regression.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore(nix): align git_version format closer to Makefile

Adds the `v` prefix and uses a 6-char SHA so Nix-built nodes report
e.g. `v0.38.1-g52e980`, matching the shape of `git describe --abbrev=6
--always --tags` aside from the unreachable commit-count segment (tag
metadata isn't exposed through the flake input protocol).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 21:57:14 +01:00

5.8 KiB
Raw Blame History

name about title labels assignees
Prepare Release Execute tasks for the creation and publishing of a new full release Prepare release 0.0.0 full-release

Items to complete

All items below are to be completed by the owner of the given release.

  • Create release branch with major and minor only ( e.g. release/v0.X ) if it doesn't exist.

  • Update the version field in waku.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.

  • 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

    • Automated testing

      • Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.

    • QA testing

      • Ask QA to run their available tests against the release candidate.

    • Waku fleet testing

      • Deploy the release candidate to waku.test fleet.
        • Start the deployment job 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.waku.org/ that the fleet is locked to the release candidate image.
        • Confirm the container image exists on Harbor.
      • Search Kibana logs from the previous month (since the last release was deployed) for possible crashes or errors in waku.test.
        • Set time range to "Last 30 days" (or since last release).
        • Most relevant search query: (fleet: "waku.test" AND message: "SIGSEGV"), (fleet: "waku.test" AND message: "exception"), (fleet: "waku.test" AND message: "error").
        • Document any crashes or errors found.
      • Ask QA to perform tests against waku.test, if any. Then, after that, review Kibana for possible issues or unexpected restart.
      • Enable the waku.test fleet again to resume auto-deployment of the latest master commit.

    • Status testing

      • Get QA approval to deploy a new version in status.staging.
      • Deploy release candidate to status.staging.
      • Perform sanity check 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 (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.

  • Proceed with release

Links