Close release 2.2.0-rc.1 #6768
Close release 2.2.0-rc.1 #6768
Conversation
📝 WalkthroughWalkthroughThis release (version 2.2.0-rc.1) introduces significant improvements to the system's reliability and functionality. The key highlight is the implementation of packet acknowledgment for every packet, which enhances communication reliability. The release addresses multiple bug fixes across various components, including issues with alias records, message sending, and pipeline build processes. It also includes improvements to API compatibility, session management, logging, and introduces new configuration options and endpoints. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/changelog/changelog-2.2.0-rc.1.md (2)
5-5: Consider adding more detailed descriptions for significant changes.Some changelog entries would benefit from additional context to help users understand their impact. For example:
- "Acknowledge every packet" - What was the previous behavior and what benefits does this change bring?
- "Invalid alias record entry attempt after hoprd node start" - What was the issue and its impact?
Also applies to: 9-23
62-62: Fix formatting inconsistencies in changelog entries.Please address the following formatting issues:
- Line 62: Add hyphen for compound adjective "backwards-compatible"
- Line 93: Add hyphen for "environment-var-based"
- Line 110: Use "an" instead of "a" before "instrumentation"
Also applies to: 93-93, 110-110
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/changelog/changelog-2.2.0-rc.1.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/changelog/changelog-2.2.0-rc.1.md
[uncategorized] ~62-~62: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... metrics to prime them - #6655 - Return backwards compatible configuration with 2.1.x versions - #66...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~93-~93: This expression is usually spelled with a hyphen.
Context: ...for the additional optional environment var based configuration - #6576 - api: Add swagge...
(BASED_HYPHEN)
[misspelling] ~110-~110: Use “an” instead of ‘a’ if the following word starts with a vowel sound, e.g. ‘an article’, ‘an hour’.
Context: ...ng probability SC address - #6513 - Add a instrumentation build for the tokio run...
(EN_A_VS_AN)
[inconsistency] ~124-~124: A new year has begun. Did you mean “2025-08-16”?
Context: ...aint Louis - #6456 - Dependency updates 2024-08-16 - #6435 - Introduce UDP session listene...
(DATE_NEW_YEAR)
⏰ Context from checks skipped due to timeout of 90000ms (8)
- GitHub Check: hoprd-x86_64-darwin / binary
- GitHub Check: hoprd-aarch64-darwin / binary
- GitHub Check: hopli-x86_64-darwin / binary
- GitHub Check: hopli-aarch64-darwin / binary
- GitHub Check: tests-unit
- GitHub Check: tests-smoke-websocket
- GitHub Check: tests-smart-contracts
- GitHub Check: tests-unit-nightly
🔇 Additional comments (1)
docs/changelog/changelog-2.2.0-rc.1.md (1)
34-35: Verify backward compatibility testing with 2.1.x versions.Multiple entries indicate backward compatibility changes with 2.1.x versions. Please ensure that:
- All compatibility changes have been thoroughly tested
- The compatibility matrix is documented
- Any breaking changes are clearly highlighted
Also applies to: 62-62, 95-95
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
deploy/compose/.env-secrets.sample (1)
9-10: LGTM! Consider enhancing the documentation.The addition of
METRICS_PUSH_KEYis well-structured and properly documented.Consider adding a comment referencing the Bitwarden secret name, similar to the script:
# User and password to access Prometheus Pushgateway. +# Get from Bitwarden secret 'Prometheus Pushgateway Hoprd Node' METRICS_PUSH_KEY=deploy/compose/prometheus/metricspusher.sh (1)
31-31: Consider validating the METRICS_PUSH_KEY format.The script should validate that the key follows the expected format (user:password) before using it with curl.
Add this validation after the existing check:
if [ -z "${METRICS_PUSH_KEY}" ]; then echo "Error: METRICS_PUSH_KEY is not set. Get from Bitwarden secret 'Prometheus Pushgateway Hoprd Node'" exit 1 fi +if ! echo "${METRICS_PUSH_KEY}" | grep -q '^[^:]\+:[^:]\+$'; then + echo "Error: METRICS_PUSH_KEY must be in the format 'user:password'" + exit 1 +fiREADME.md (2)
Line range hint
201-201: Fix typo in About section.There's a typo in the word "modiyfing" which should be "modifying".
-The HOPR project produces multiple artifacts that allow running, maintaining and modiyfing the HOPR node. +The HOPR project produces multiple artifacts that allow running, maintaining and modifying the HOPR node.
97-97: Consider removing dollar signs from command examples.The dollar sign prefix in command examples can interfere with copy-paste functionality. Consider removing them for better user experience.
-$ docker pull europe-west3-docker.pkg.dev/hoprassociation/docker-images/hoprd:singapore +docker pull europe-west3-docker.pkg.dev/hoprassociation/docker-images/hoprd:singapore🧰 Tools
🪛 Markdownlint (0.37.0)
97-97: null
Dollar signs used before commands without showing output(MD014, commands-show-output)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
.github/workflows/close-release.yaml(0 hunks).github/workflows/publish-release.yaml(1 hunks).processes/release.md(1 hunks)README.md(2 hunks)deploy/compose/.env-secrets.sample(1 hunks)deploy/compose/README.md(1 hunks)deploy/compose/docker-compose.yml(0 hunks)deploy/compose/prometheus/metricspusher.sh(2 hunks)releases.json(1 hunks)scripts/deploy-rotsee-nodes.sh(1 hunks)scripts/merge-back.sh(0 hunks)
💤 Files with no reviewable changes (3)
- scripts/merge-back.sh
- deploy/compose/docker-compose.yml
- .github/workflows/close-release.yaml
✅ Files skipped from review due to trivial changes (3)
- .github/workflows/publish-release.yaml
- scripts/deploy-rotsee-nodes.sh
- .processes/release.md
🧰 Additional context used
🪛 Markdownlint (0.37.0)
README.md
97-97: null
Dollar signs used before commands without showing output
(MD014, commands-show-output)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: hoprd-x86_64-darwin / binary
- GitHub Check: hoprd-aarch64-darwin / binary
- GitHub Check: hopli-x86_64-darwin / binary
- GitHub Check: hopli-aarch64-darwin / binary
🔇 Additional comments (4)
deploy/compose/prometheus/metricspusher.sh (1)
9-12: LGTM! The validation is properly implemented.The check for
METRICS_PUSH_KEYis consistent with other validations and includes helpful information about retrieving the credentials.deploy/compose/README.md (1)
61-61: LGTM! Documentation is clear and complete.The documentation properly explains the new
METRICS_PUSH_KEYrequirement and includes the source of credentials.README.md (2)
85-85: LGTM! Release version updates are consistent.The release version has been correctly updated from 'saint-louis' to 'singapore' in both the
$RELEASEvariable example and the Docker pull command, aligning with the PR objectives for release 2.2.0-rc.1.Also applies to: 97-97
Line range hint
1-999: Documentation is comprehensive and well-maintained.The README provides thorough coverage of installation, usage, development setup, and testing procedures. The updates align well with the PR objectives and accurately reflect the new features mentioned in the release.
| "singapore": { | ||
| "git_ref": "^release/singapore$", | ||
| "network": "dufour", | ||
| "version_major": "2", | ||
| "version_minor": "2" | ||
| }, |
There was a problem hiding this comment.
💡 Codebase verification
Git ref pattern needs to be updated for staging support
The verification confirms that the git_ref pattern for singapore (^release/singapore$) deviates from the standard pattern used by all other releases (^(release|staging)/name$). Update it to ^(release|staging)/singapore$ to maintain consistency and enable staging deployments.
🔗 Analysis chain
Verify the git ref pattern for consistency.
The git_ref pattern ^release/singapore$ differs from other entries that use ^(release|staging)/name$. This might prevent staging deployments.
Run this script to check the pattern consistency:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check git ref patterns in releases.json
jq -r 'to_entries[] | select(.key != "development" and .key != "debug-staging" and .key != "integration-test") | [.key, .value.git_ref] | @tsv' releases.json | while IFS=$'\t' read -r release pattern; do
if [[ $pattern != *"(release|staging)"* ]]; then
echo "Warning: $release has non-standard git_ref pattern: $pattern"
fi
done
Length of output: 1133
This Pull requests contains all the required changes needed before releasing a new version.
Check that there is an entry in
releases.jsonfor the new release name.hopr/hopr-lib/data/protocol-config.jsonshould be created for the network.dufourthen update the filehopr/hopr-lib/data/protocol-config.jsonfor thedufourentry to accept the newversion_rangeof the new release.Change all occurences of the last release name to the new release name within documentation files and Docker files. Don't touch the
protocol-config.jsonandreleases.jsonfiles in this step.Check the milestone contents and that all items are closed. And there is no missing issue or PR to be included.
If the release will run in a new network then, check that the entry
networksincontracts-addresses.json, contains its own networkNOTE: Don't include the deployment of HoprChannels, because this will be re-deployed anyway by the CD system.
Changes should be committed locally.
Assess that all CI checks have passed successfully and wait for the docker images builds to finish.
Check that binary x86_64-linux works correctly by setting up a node on that architecture and operative system
Check that binary aarch64-linux works correctly by setting up a node on that architecture and operative system
Check that binary aarch64-darwin works correctly by setting up a node on that architecture and operative system
Check that binary x86_64-darwin works correctly by setting up a node on that architecture and operative system
Create a new baseline for load testing following Load testing guide.
Get the approval from at least 2 members