feat: publish release candidates - #1139
Conversation
WalkthroughThe publish workflow’s tag trigger and version-parsing regexes were updated to support turbo tags with optional RC suffixes, and the job now hard-fails when tag parsing fails. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Dev as Developer
participant GH as GitHub
participant WF as Publish Workflow
participant PyPI as PyPI
Dev->>GH: Push tag agent-builder-turbo-<ver[-rcN]>-image-<img>-main
GH-->>WF: Trigger on tag match
WF->>WF: Extract version via updated regex
alt Version parsed
WF->>PyPI: Publish (handles rc if present)
PyPI-->>WF: Publish result
else Parse failure
WF->>WF: Exit 1 (fail job)
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/publish.yml (1)
34-37: Add python-version to setup-python step (required; cache key needs it).Without
python-version, this step can fail and cache won’t key properly.Apply this diff:
uses: actions/setup-python@v5 with: - cache: 'poetry' + python-version: '3.12' + cache: 'poetry' + cache-dependency-path: 'poetry.lock'If your project standardizes on another version, set that instead or use
python-version-file: '.python-version'.
🧹 Nitpick comments (2)
.github/workflows/publish.yml (2)
39-43: Optional: improve npm caching effectiveness.If npm is used in later steps (e.g., via alfred), add cache keying to lockfile.
Apply this diff:
with: node-version: "22.x" - cache: npm + cache: npm + cache-dependency-path: '**/package-lock.json'
11-11: Optional: consider increasing job timeout.Publishing + dependency resolution can exceed 10 minutes in CI. Consider 15–20 minutes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/publish.yml(2 hunks)
⏰ 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). (13)
- GitHub Check: build (3.13)
- GitHub Check: build (3.10)
- GitHub Check: build (3.12)
- GitHub Check: build (3.9)
- GitHub Check: build (3.11)
- GitHub Check: tests (firefox)
- GitHub Check: tests (webkit)
- GitHub Check: build (3.13)
- GitHub Check: tests (chromium)
- GitHub Check: build (3.12)
- GitHub Check: build (3.11)
- GitHub Check: build (3.9)
- GitHub Check: build (3.10)
🔇 Additional comments (1)
.github/workflows/publish.yml (1)
20-25: LGTM: robust version parsing with hard fail on mismatch.Anchored regex with
BASH_REMATCH+exit 1is correct and safe.Please confirm that tags will be pushed in the exact form your regex expects (e.g., agent-builder-turbo-1.2.3rc1-image-4.5.6-main and agent-builder-turbo-1.2.3-image-4.5.6-main).
There was a problem hiding this comment.
HackerOne Code Security Review
🟢 Scan Complete: 1 Issue(s)
🟢 Validation Complete: Any Issues detected were validated by one of our engineers. None were determined to require immediate action.
Here's how the code changes were interpreted and info about the tools used for scanning.
📖 Summary of Changes
The GitHub Actions workflow configuration for publishing was modified to enhance version tag parsing. The update adjusts the regex pattern to accommodate more flexible version naming conventions, specifically allowing for release candidate (rc) tags with additional version components.
| File | Summary |
|---|---|
| .github/workflows/publish.yml | The workflow tag pattern was updated to support optional release candidate (rc) versioning, modifying the regex to allow for additional version components like "rc1" in the tag name. |
ℹ️ Issues Detected
NOTE: These may not require action!
Below are unvalidated results from the Analysis Tools that ran during the latest scan for transparency. We investigate each of these for accuracy and relevance before surfacing them as a potential problem.
How will I know if something is a problem?
When validation completes, any concerns that warrant attention prior to merge will be posted as inline comments. These will show up in 2 ways:
- Expert review (most cases): Issues will be posted by experts who manually reviewed and validated them. These are real HackerOne engineers (not bots) reviewing through an integrated IDE-like tool. You can communicate with them like any other reviewer. They'll stay assigned and get notified with commit & comment updates.
- Automatically: In cases where our validation checks have highest confidence the problem is legitimate and urgent. These will include a description of contextual reasoning why & actionable next steps.
| File & Line | Issue |
|---|---|
.github/workflows/publish.yml Line 20 |
The regex pattern change in line 20 extracts version information from the tag, but now the version is stored in BASH_REMATCH[1] which includes the 'rc' suffix if present. This could lead to unexpected behavior when using this version string in the 'poetry version' command on line 45, potentially causing versioning issues or publishing incorrect package versions. The regex capture groups should be adjusted to properly handle the optional 'rc' component. |
🧰 Analysis tools
- [ ✅ ] HackerOne AI Code Analysis
- [ ✅ ] HackerOne AI Code Validation
- [ ✅ ] semgrep
- [ ✅ ] bandit
There was a problem hiding this comment.
✅ Francisco P reviewed all the included code changes and associated automation findings and determined that there were no immediately actionable security flaws. Note that they will continue to be notified of any new commits or comments and follow up as needed throughout the duration of this pull request's lifecycle.
Reviewed with ❤️ by PullRequest
Summary by CodeRabbit