chore: add release workflow and version-aware Docker image tags - #30
Conversation
|
/review |
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe pull request adds a manual release workflow for synchronized semantic version updates and changes Docker image publishing to produce both ChangesRelease and image versioning
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Maintainer
participant ReleaseWorkflow
participant Repository
participant GitRemote
Maintainer->>ReleaseWorkflow: Submit X.Y.Z version
ReleaseWorkflow->>Repository: Update project and workflow versions
ReleaseWorkflow->>Repository: Run uv lock and commit changes
ReleaseWorkflow->>GitRemote: Push master branch and annotated tag
sequenceDiagram
participant ImageWorkflow
participant Buildx
participant ContainerRegistry
ImageWorkflow->>Buildx: Create multi-architecture manifest
Buildx->>ContainerRegistry: Push latest image tag
Buildx->>ContainerRegistry: Push version-specific image tag
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
@copilot review this PR |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #30 +/- ##
=======================================
Coverage 99.49% 99.49%
=======================================
Files 39 39
Lines 5506 5506
Branches 319 319
=======================================
Hits 5478 5478
Misses 17 17
Partials 11 11 ☔ View full report in Codecov by Harness. |
Two bugs fixed in
Everything else looks good:
|
There was a problem hiding this comment.
Pull request overview
This PR bumps the weather-briefing project version to 0.3.0 and aligns release automation around that version, including publishing Docker images tagged as both latest and the exact version, plus adding a GitHub Actions workflow to create git tags on version bumps.
Changes:
- Bump project version from
0.2.0to0.3.0acrosspyproject.toml, package__init__, anduv.lock. - Update the container multi-arch manifest publish step to tag images as both
:latestand:0.3.0. - Add a
release.ymlworkflow that reads the version frompyproject.tomland creates an annotated git tag.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| weather_briefing/init.py | Bumps the runtime package __version__ to 0.3.0. |
| uv.lock | Updates the lockfile’s editable package version to 0.3.0. |
| pyproject.toml | Bumps the project version to 0.3.0. |
| .github/workflows/release.yml | Adds an automated release-tagging workflow on version bumps. |
| .github/workflows/image.yml | Publishes multi-arch images with both latest and version tags. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
54c1ca1 to
523e788
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
49-51: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winHandle empty commits to prevent workflow crashes.
If the workflow is accidentally rerun for an already-bumped version (or if the files are already up-to-date),
git commitwill fail because there are no staged changes, crashing the workflow. Adding a check avoids this failure.♻️ Proposed refactor
git add pyproject.toml weather_briefing/__init__.py .github/workflows/image.yml uv.lock - git commit -m "chore: bump version to ${VERSION}" + if ! git diff --cached --quiet; then + git commit -m "chore: bump version to ${VERSION}" + else + echo "No changes to commit, proceeding to tag." + fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 49 - 51, Update the release workflow’s version-bump commit step to tolerate cases where the staged files have no changes, so rerunning an already-completed version bump does not fail. Guard the git commit after the existing `git add` using a staged-change check, while preserving the current commit message and file list when changes are present.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 13-14: Restrict the release job identified by release to execute
only when the workflow runs on the master branch, using the job-level condition
while preserving its existing runs-on configuration and release steps.
- Around line 45-59: Update the release workflow’s git remote authentication and
push commands to use a configured Personal Access Token secret instead of the
default GITHUB_TOKEN. Ensure the token is exposed through the workflow
environment and used by the remote URL so both the master push and version tag
push trigger downstream workflows such as image.yml.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 49-51: Update the release workflow’s version-bump commit step to
tolerate cases where the staged files have no changes, so rerunning an
already-completed version bump does not fail. Guard the git commit after the
existing `git add` using a staged-change check, while preserving the current
commit message and file list when changes are present.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: eddf706e-1fc5-4ae4-8d5e-6ef54f2f05e5
📒 Files selected for processing (2)
.github/workflows/image.yml.github/workflows/release.yml
69f2daf to
ceb3c25
Compare
- Docker image now tagged with both :latest and :VERSION - New release workflow (manual workflow_dispatch) updates pyproject.toml, __init__.py, image.yml, uv.lock, creates a git tag, and pushes to master
ceb3c25 to
138ef8a
Compare
Changes
:latestand:VERSION(hardcoded inimage.yml).github/workflows/release.yml: manualworkflow_dispatchwith version inputRelease workflow
pyproject.toml,__init__.py,image.ymlwith the new versionuv lockto sync lockfileSummary by CodeRabbit
New Features
latestand version-specific tags.Chores