feat: auto-release after merge + version in issue closing comments#4957
feat: auto-release after merge + version in issue closing comments#4957marcusquinn merged 1 commit intomainfrom
Conversation
Two gaps in the full-loop workflow: 1. After merging a PR on the aidevops repo, no release was cut — fixes sat on main until someone manually released. Contributors running aidevops update got nothing. Now the full-loop auto-bumps a patch version, tags, and creates a GitHub release after every merge. 2. Issue closing comments didn't tell the reporter which version contained the fix. Now the template includes a 'Released in: vX.Y.Z' line with 'run aidevops update to get this fix' so reporters know exactly when and how to pick up the solution. Auto-release is aidevops-repo-only and always uses patch (workers can't determine if a change is minor/major — that requires human judgment).
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Caution Review failedPull request was closed or merged during review WalkthroughThe pull request modifies a DevOps automation documentation file to reorder post-merge finalization steps, introduce an auto-release workflow for the aidevops repository that automates version bumping and release creation, and enhance issue closing comments with release version tracking information. Changes
Sequence DiagramsequenceDiagram
participant PR as PR/Merge System
participant Git as Git Operations
participant GH as GitHub API
participant Issue as Issue Tracker
participant Deploy as Deployment System
PR->>Git: Auto-Release: Pull canonical main
Git->>Git: Bump patch version
Git->>Git: Commit & create tag
Git->>GH: Push commits and tags
GH->>GH: Create release with notes
GH-->>PR: Release created (version)
PR->>Issue: Close issue with "Released in v{version}"
Issue-->>PR: Issue marked as released
PR->>Deploy: Worktree cleanup
Deploy->>Deploy: Postflight checks
Deploy->>Deploy: Deploy updated code
Estimated Code Review Effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Sun Mar 15 21:12:46 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces an automated release process after a merge, which is a great improvement for closing the loop with contributors. The changes also include adding the release version to issue closing comments, which enhances communication. My review focuses on the new bash script for auto-releasing. I've identified a few potential issues related to robustness and correctness that could affect the reliability of the new automation. Specifically, I've made suggestions to ensure scripts are run in the correct directory context, to make the automation truly non-interactive, and to improve consistency.
| git -C "$CANONICAL_DIR" pull origin main | ||
|
|
||
| # Bump patch version (updates VERSION, package.json, setup.sh, etc.) | ||
| "$HOME/.aidevops/agents/scripts/version-manager.sh" bump patch |
There was a problem hiding this comment.
The version-manager.sh script is called without changing the directory to $CANONICAL_DIR. If this script operates on the current working directory, it will modify files in the worktree instead of the main repository checkout. This would lead to the version bump not being part of the release commit. To ensure the version is bumped in the correct location, you should change into the canonical directory before running the script.
| "$HOME/.aidevops/agents/scripts/version-manager.sh" bump patch | |
| (cd "$CANONICAL_DIR" && "$HOME/.aidevops/agents/scripts/version-manager.sh" bump patch) |
| --generate-notes | ||
|
|
||
| # Deploy locally | ||
| "$CANONICAL_DIR/setup.sh" 2>/dev/null || true |
There was a problem hiding this comment.
The PR description and the step list in this document both state that setup.sh should be run with --non-interactive. However, the flag is missing in the script snippet. Without it, the script might hang waiting for user input in an automated context. Additionally, 2>/dev/null || true suppresses all errors from the local deployment step, which could hide important issues. It's better to be explicit about non-interactive mode and allow errors to be visible.
| "$CANONICAL_DIR/setup.sh" 2>/dev/null || true | |
| "$CANONICAL_DIR/setup.sh" --non-interactive || true |
|
|
||
| # Commit, tag, push, create release | ||
| git -C "$CANONICAL_DIR" add -A | ||
| git -C "$CANONICAL_DIR" commit -m "chore(release): bump version to ${NEW_VERSION}" |
There was a problem hiding this comment.
The git tag for the release is created with a 'v' prefix (e.g., v1.2.3), but the commit message for the version bump does not include this prefix. For consistency in versioning artifacts, it's good practice to use the same version format in both the commit message and the tag.
| git -C "$CANONICAL_DIR" commit -m "chore(release): bump version to ${NEW_VERSION}" | |
| git -C "$CANONICAL_DIR" commit -m "chore(release): bump version to v${NEW_VERSION}" |
Fix 2 of 3 review findings from PR #4957 (Gemini Code Assist): 1. CRITICAL: version-manager.sh now runs inside a (cd $CANONICAL_DIR) subshell so the version bump targets the main repo checkout, not the worktree. Without this, the bumped VERSION file would be written to the worktree and never included in the release commit. 2. HIGH: setup.sh now passes --non-interactive to prevent hanging in automated/headless contexts. Removed 2>/dev/null stderr suppression so deployment errors are visible. 3. MEDIUM (dismissed): commit message v-prefix suggestion conflicts with the established repo convention (commits use bare version, tags use v-prefix — see git log --grep='chore(release)'). Closes #4958
1 participant
Summary
--generate-notes, and deploys viasetup.sh. This closes the gap where fixes sat on main indefinitely until someone manually released.aidevops updateto get this fix" line, so reporters know exactly which version contains their fix and how to get it.Motivation
When a contributor (e.g., robstiles on issue #4954) reports a bug and a worker fixes it, the loop ended at merge + deploy. But deploy only updates the local machine — other contributors running
aidevops updategot nothing because no release was tagged. The reporter had no way to know the fix was available.Design decisions
REPO_SLUG == "marcusquinn/aidevops".--generate-notes— Avoids the need for workers to compose release notes. GitHub auto-generates from commit messages.Verification
Markdown lint passes clean. Single file changed (full-loop.md), no shell scripts modified.
Summary by CodeRabbit