Release pipeline #876
Release pipeline #876
Conversation
fix poetry installation
shichengripple001
dismissed stale reviews from kuan121 and Patel-Raj11
via
e062ace
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/release.yml (2)
638-638: Consider using an environment variable for the package name in Slack messages.Line 638 hardcodes
"xrpl-py"in the Slack success message. While this works for this specific project, using an environment variable (PACKAGE_NAME: xrpl-pyin the step'senvblock) would improve reusability and consistency with the pattern used elsewhere in the workflow.- name: Notify Slack success (single-line) if: success() env: SLACK_TOKEN: ${{ secrets.SLACK_TOKEN }} + PACKAGE_NAME: xrpl-py REPO: ${{ github.repository }} PACKAGE_VERSION: ${{ env.PACKAGE_VERSION }} TAG: ${{ env.PACKAGE_VERSION }} run: | set -euo pipefail TAG="${TAG:-${PACKAGE_VERSION}}" RELEASE_URL="https://github.com/$REPO/releases/tag/v$TAG" - text="xrpl-py ${PACKAGE_VERSION} has been successfully released and published to pypi. Release URL: ${RELEASE_URL}" + text="${PACKAGE_NAME} ${PACKAGE_VERSION} has been successfully released and published to pypi. Release URL: ${RELEASE_URL}"
155-159: Refactor repetitive conditional logic across jobs.Multiple jobs (pre-release, ask_for_dev_team_review, first_review, ask_for_sec_team_review, publish-to-pypi, github-release) repeat similar multi-line conditions. For example:
if: ${{ always() && needs.input-validate.result == 'success' && (needs['faucet-tests'].result == 'success' || needs.input-validate.outputs.is_beta_release == 'true') && (needs['integration-tests'].result == 'success' || needs.input-validate.outputs.is_beta_release == 'true') && (needs['unit-tests'].result == 'success' || needs.input-validate.outputs.is_beta_release == 'true') }}This pattern is duplicated across 6 jobs with variations. Consider extracting a reusable conditional expression or defining a helper job to reduce repetition and improve maintainability.
Also applies to: 320-325, 453-458, 477-483, 523-530, 575-583
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/release.yml(1 hunks)pyproject.toml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- pyproject.toml
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 760
File: .github/workflows/publish_to_pypi.yml:2-5
Timestamp: 2024-10-29T22:43:40.212Z
Learning: In the `.github/workflows/publish_to_pypi.yml` file, when configuring the tag pattern for triggering the release workflow, use the flexible pattern `'*'` instead of restricting to version tags. This allows for releasing specific feature builds (like AMM, MPT, etc.) and provides more flexibility in the tagging process.
📚 Learning: 2024-10-29T22:43:40.212Z
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 760
File: .github/workflows/publish_to_pypi.yml:2-5
Timestamp: 2024-10-29T22:43:40.212Z
Learning: In the `.github/workflows/publish_to_pypi.yml` file, when configuring the tag pattern for triggering the release workflow, use the flexible pattern `'*'` instead of restricting to version tags. This allows for releasing specific feature builds (like AMM, MPT, etc.) and provides more flexibility in the tagging process.
Applied to files:
.github/workflows/release.yml
📚 Learning: 2025-04-07T23:32:27.184Z
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 824
File: tools/fetch_rippled_amendments.py:0-0
Timestamp: 2025-04-07T23:32:27.184Z
Learning: For CI/CD scripts in the xrpl-py repository, ckeshava prefers concise code over comprehensive error handling since developers can check the logs for error details.
Applied to files:
.github/workflows/release.yml
📚 Learning: 2024-10-30T20:34:35.451Z
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 759
File: xrpl/models/transactions/credential_delete.py:57-68
Timestamp: 2024-10-30T20:34:35.451Z
Learning: Consistent implementation patterns are preferred in the `xrpl-py` codebase, especially in transaction models under `xrpl/models/transactions/`. When suggesting refactoring that affects multiple transactions, consider the impact on overall consistency and propose comprehensive changes when appropriate.
Applied to files:
.github/workflows/release.yml
📚 Learning: 2024-10-30T21:01:15.823Z
Learnt from: mvadari
Repo: XRPLF/xrpl-py PR: 759
File: tests/integration/transactions/test_credential.py:42-44
Timestamp: 2024-10-30T21:01:15.823Z
Learning: In this codebase, extensive unit tests are located in `rippled`, and additional tests are not required in this library.
Applied to files:
.github/workflows/release.yml
📚 Learning: 2024-12-12T00:26:03.754Z
Learnt from: mvadari
Repo: XRPLF/xrpl-py PR: 759
File: .github/workflows/integration_test.yml:5-5
Timestamp: 2024-12-12T00:26:03.754Z
Learning: The rippled Docker image for integration tests should use stable versions (e.g., 2.3.0) instead of release candidates (e.g., 2.3.0-rc1) to ensure stability in CI.
Applied to files:
.github/workflows/release.yml
📚 Learning: 2024-12-12T00:48:38.042Z
Learnt from: mvadari
Repo: XRPLF/xrpl-py PR: 759
File: tests/unit/models/transactions/test_account_delete.py:52-60
Timestamp: 2024-12-12T00:48:38.042Z
Learning: The credential ID format validation for xrpl-py is being tracked in issue #766 and should not be duplicated in other PRs.
Applied to files:
.github/workflows/release.yml
🔇 Additional comments (2)
.github/workflows/release.yml (2)
233-310: Workflow permits release despite security vulnerabilities, relying on manual gates instead of automated enforcement.The Trivy scan uses
exit-code: 0, allowing the pipeline to continue regardless of findings. While the workflow creates a GitHub issue for visibility and passes the vulnerability report to the security team for review, no downstream job condition is programmatically tied to vulnerability detection. Specifically,found_vulnerabilityoutput is never used downstream—all jobs only checkpre-release.result == 'success'.The workflow does include manual approval gates (
first_reviewandofficial-releaseenvironments) where reviewers can block releases, and the security team receives the vulnerability report URL for this review. However, this approval is a manual process, not an automated gate. If the intent is to enforce automated blocking on vulnerabilities:
- Export
found_vulnerabilityfrom pre-release job as a job output- Add explicit condition to
publish-to-pypi: requireneeds.pre-release.outputs.found_vulnerability == 'false'- Alternatively, document that vulnerability blocking relies entirely on environment approval process
155-159: Test-skipping for beta releases is intentional and has documented compensating controls.The review comment mischaracterizes the beta release behavior. While unit, faucet, and integration tests are intentionally skipped for beta versions (detected from version strings containing
a,b, orrc), the RELEASE.md playbook explicitly documents this design decision as part of a fast-track strategy for pre-release iterations.The workflow includes safeguards that address the original concern:
- Vulnerability scanning still runs: The
pre-releasejob generates a CycloneDX SBOM and scans it with Trivy regardless of release type, creating GitHub issues for CRITICAL/HIGH findings.- Security team review required: Beta releases route through a
beta-releaseapproval environment; security reviewers are notified via Slack and must approve in GitHub.- Dev team oversight: Both beta and stable releases trigger dev team notifications and approval gates, with betas using a distinct
beta-releaseenvironment.This is a deliberate trade-off to enable faster beta iteration while maintaining security oversight. The workflow design aligns with the documented release strategy in RELEASE.md.
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
RELEASE.md (1)
16-17: Add missing article for clarity.Line 17 reads "by reading version under the [project] section" but should include the article "the" before "version":
-and standard releases by reading version under the [project] section from `pyproject.toml`: +and standard releases by reading the version under the [project] section from `pyproject.toml`:
🧹 Nitpick comments (1)
RELEASE.md (1)
20-21: Standardize prerelease terminology in prose.The document mixes "prerelease" (one word) and "pre-release" (hyphenated) inconsistently in prose descriptions. To maintain consistency: keep
--prereleasein code/flag contexts and use "pre-release" uniformly in prose throughout.Lines to update:
- Line 21: "beta/prerelease builds" → "beta/pre-release builds"
- Line 74: "for prereleases" → "for pre-releases"
- - The `latest` tag on GitHub remains unchanged (beta/prerelease builds do not become the + - The `latest` tag on GitHub remains unchanged (beta/pre-release builds do not become the default download).job (or the - `beta-release` gate for prereleases). + `beta-release` gate for pre-releases).Also applies to: 63-63, 74-74
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
RELEASE.md(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 760
File: .github/workflows/publish_to_pypi.yml:2-5
Timestamp: 2024-10-29T22:43:40.212Z
Learning: In the `.github/workflows/publish_to_pypi.yml` file, when configuring the tag pattern for triggering the release workflow, use the flexible pattern `'*'` instead of restricting to version tags. This allows for releasing specific feature builds (like AMM, MPT, etc.) and provides more flexibility in the tagging process.
📚 Learning: 2024-10-29T22:43:40.212Z
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 760
File: .github/workflows/publish_to_pypi.yml:2-5
Timestamp: 2024-10-29T22:43:40.212Z
Learning: In the `.github/workflows/publish_to_pypi.yml` file, when configuring the tag pattern for triggering the release workflow, use the flexible pattern `'*'` instead of restricting to version tags. This allows for releasing specific feature builds (like AMM, MPT, etc.) and provides more flexibility in the tagging process.
Applied to files:
RELEASE.md
📚 Learning: 2024-11-01T20:30:25.301Z
Learnt from: mvadari
Repo: XRPLF/xrpl-py PR: 765
File: xrpl/models/transactions/xchain_add_claim_attestation.py:34-46
Timestamp: 2024-11-01T20:30:25.301Z
Learning: When creating GitHub issues for future improvements, ensure they are general and apply across the codebase, rather than specific to a single type, when requested by the user.
Applied to files:
RELEASE.md
📚 Learning: 2025-04-07T23:32:27.184Z
Learnt from: ckeshava
Repo: XRPLF/xrpl-py PR: 824
File: tools/fetch_rippled_amendments.py:0-0
Timestamp: 2025-04-07T23:32:27.184Z
Learning: For CI/CD scripts in the xrpl-py repository, ckeshava prefers concise code over comprehensive error handling since developers can check the logs for error details.
Applied to files:
RELEASE.md
🪛 LanguageTool
RELEASE.md
[uncategorized] ~4-~4: The official name of this software platform is spelled with a capital “H”.
Context: ...? to PyPIGitHub Actions workflow (see.github/workflows/release.yml`). ## 0. Configu...
(GITHUB)
[uncategorized] ~20-~20: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ... The GitHub Release is created with the --prerelease flag. - The latest tag on GitHub r...
(EN_WORD_COHERENCY)
[uncategorized] ~21-~21: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ...` tag on GitHub remains unchanged (beta/prerelease builds do not become the default do...
(EN_WORD_COHERENCY)
[grammar] ~39-~39: Ensure spelling is correct
Context: ...or branch name. - A PR to main is not mandotary. The workflow will fail immediately if...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[uncategorized] ~63-~63: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ... creates or updates the GitHub Release (--prerelease for beta versions, --latest for stab...
(EN_WORD_COHERENCY)
[uncategorized] ~74-~74: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ...job (or the beta-release` gate for prereleases). ## 4. Verify Publication & Finish Up...
(EN_WORD_COHERENCY)
[style] ~89-~89: Consider using “email”.
Context: ...sion or updating docs) if needed. 6. Send an email to [xrpl-announce](https://groups.google.c...
(SEND_AN_EMAIL)
[uncategorized] ~100-~100: The official name of this software platform is spelled with a capital “H”.
Context: ...tomation needs adjustments, update both .github/workflows/release.yml and this guide s...
(GITHUB)
[uncategorized] ~104-~104: The official name of this software platform is spelled with a capital “H”.
Context: ... ## Manual Release process(Just in case Github action is not available for unforseeabl...
(GITHUB)
[style] ~110-~110: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...hanges should have passed the linter. - Your code should pass all the unit and integ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~110-~110: The official name of this software platform is spelled with a capital “H”.
Context: ...s all the unit and integration tests on Github (which check all versions of Python). -...
(GITHUB)
[uncategorized] ~125-~125: The official name of this software platform is spelled with a capital “H”.
Context: ... pypi publishing token. 6. Create a new Github release/tag off of this branch. 7. Send...
(GITHUB)
[style] ~125-~125: ‘off of’ might be wordy. Consider a shorter alternative.
Context: ...ken. 6. Create a new Github release/tag off of this branch. 7. Send an email to [xrpl-...
(EN_WORDINESS_PREMIUM_OFF_OF)
[style] ~126-~126: Consider using “email”.
Context: ...thub release/tag off of this branch. 7. Send an email to [xrpl-announce](https://groups.google.c...
(SEND_AN_EMAIL)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
- GitHub Check: Integration test (3.14)
- GitHub Check: Integration test (3.13)
- GitHub Check: Integration test (3.12)
- GitHub Check: Integration test (3.10)
- GitHub Check: Integration test (3.11)
- GitHub Check: Integration test (3.8)
- GitHub Check: Integration test (3.9)
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: semgrep-cloud-platform/scan
| default download). | ||
|
|
||
| - **Stable release**: | ||
| - A PR from the release branch to `main` is must exist before triggering the pipeline. |
There was a problem hiding this comment.
Fix redundant/malformed auxiliary verb.
Line 25 contains "A PR from the release branch to main is must exist", which has a grammatical error. The phrasing should be either "A PR... must exist" or "A PR... is required".
- - A PR from the release branch to `main` is must exist before triggering the pipeline.
+ - A PR from the release branch to `main` must exist before triggering the pipeline.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - A PR from the release branch to `main` is must exist before triggering the pipeline. | |
| - A PR from the release branch to `main` must exist before triggering the pipeline. |
🤖 Prompt for AI Agents
In RELEASE.md around line 25, the sentence "A PR from the release branch to
`main` is must exist before triggering the pipeline." has a redundant/malformed
auxiliary verb; replace it with a correct phrasing such as "A PR from the
release branch to `main` must exist before triggering the pipeline." (or
alternatively "A PR from the release branch to `main` is required before
triggering the pipeline.") so the sentence is grammatically correct.
|
|
||
| - **Beta release**: | ||
| - There is no restriction for branch name. | ||
| - A PR to main is not mandotary. |
There was a problem hiding this comment.
Fix typo: "mandotary" → "mandatory".
- - A PR to main is not mandotary.
+ - A PR to main is not mandatory.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - A PR to main is not mandotary. | |
| - A PR to main is not mandatory. |
🧰 Tools
🪛 LanguageTool
[grammar] ~39-~39: Ensure spelling is correct
Context: ...or branch name. - A PR to main is not mandotary. The workflow will fail immediately if...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In RELEASE.md around line 39, the word "mandotary" is misspelled; replace
"mandotary" with the correct spelling "mandatory" to fix the typo.
| this guide so they stay in sync. | ||
|
|
||
|
|
||
| ## Manual Release process(Just in case Github action is not available for unforseeable reason) |
There was a problem hiding this comment.
Fix GitHub capitalization and wording in manual release section.
Three instances of "Github" (lowercase 'h') should be capitalized to "GitHub" per official naming. Additionally, line 104 contains a spelling error and line 125 uses wordy phrasing:
-## Manual Release process(Just in case Github action is not available for unforseeable reason)
+## Manual Release process (Just in case GitHub action is not available for unforeseen reason)-- Your code should pass all the unit and integration tests on Github (which check all versions of Python).
+- Your code should pass all the unit and integration tests on GitHub (which check all versions of Python).-6. Create a new Github release/tag off of this branch.
+6. Create a new GitHub release/tag off this branch.Also applies to: 110-110, 125-125
🧰 Tools
🪛 LanguageTool
[uncategorized] ~104-~104: The official name of this software platform is spelled with a capital “H”.
Context: ... ## Manual Release process(Just in case Github action is not available for unforseeabl...
(GITHUB)
🤖 Prompt for AI Agents
In RELEASE.md around lines 104, 110 and 125, fix capitalization and wording in
the Manual Release section: change all occurrences of "Github" to the proper
"GitHub", correct the misspelling "unforseeable" to "unforeseeable" on line 104,
and simplify the phrase on line 125 to a concise wording such as "Just in case
GitHub Actions is not available" (or equivalent brief phrasing) to remove
wordiness; ensure consistency across the three referenced lines.
5 participants
High Level Overview of Change
Revamp release pipeline to run tests, scan for vulnerabilities, request for review
Context of Change
Type of Change
Did you update CHANGELOG.md?
Test Plan