feat(supervisor): add automatic release at batch milestones (t128.10)#460
feat(supervisor): add automatic release at batch milestones (t128.10)#460marcusquinn merged 1 commit intomainfrom
Conversation
Add release_on_complete flag and release_type to batches, enabling automatic version-manager.sh release when all tasks in a batch complete. - Schema: release_on_complete (INTEGER, default 0) and release_type (TEXT, default 'patch') columns on batches table with migration - trigger_batch_release(): pulls main, runs version-manager.sh release with --skip-preflight, stores success/failure in memory, sends notifications, non-blocking on failure - check_batch_completion(): wired to trigger release when batch completes and release_on_complete=1 - cmd_batch(): --release-on-complete and --release-type flags - cmd_release(): manual trigger, enable/disable, dry-run support - Status display: shows release config in batch status and overview - Help text: full documentation with examples
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ 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 |
Summary of ChangesHello @marcusquinn, 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 significantly enhances the supervisor's batch management capabilities by introducing automated version releases. It allows users to define a release type (major, minor, or patch) that will be automatically executed via 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
|
🔍 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: Sat Feb 7 19:14:02 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 a well-implemented feature for automatic releases upon batch completion. The changes are comprehensive, including schema migration, new commands (release, trigger_batch_release), updates to existing logic, and thorough documentation. The code is robust with solid error handling and logging. I've made a couple of suggestions to consolidate database queries for improved efficiency, but overall, this is a high-quality contribution.
| total_tasks=$(db "$SUPERVISOR_DB" " | ||
| SELECT count(*) FROM batch_tasks WHERE batch_id = '$escaped_batch'; | ||
| ") | ||
| complete_count=$(db "$SUPERVISOR_DB" " | ||
| SELECT count(*) FROM batch_tasks bt JOIN tasks t ON bt.task_id = t.id | ||
| WHERE bt.batch_id = '$escaped_batch' AND t.status IN ('complete', 'deployed', 'merged'); | ||
| ") | ||
| failed_count=$(db "$SUPERVISOR_DB" " | ||
| SELECT count(*) FROM batch_tasks bt JOIN tasks t ON bt.task_id = t.id | ||
| WHERE bt.batch_id = '$escaped_batch' AND t.status IN ('failed', 'blocked'); | ||
| ") |
There was a problem hiding this comment.
These three separate database queries to fetch total_tasks, complete_count, and failed_count can be combined into a single, more efficient query using conditional aggregation. This reduces the number of round-trips to the database and simplifies the code.
| total_tasks=$(db "$SUPERVISOR_DB" " | |
| SELECT count(*) FROM batch_tasks WHERE batch_id = '$escaped_batch'; | |
| ") | |
| complete_count=$(db "$SUPERVISOR_DB" " | |
| SELECT count(*) FROM batch_tasks bt JOIN tasks t ON bt.task_id = t.id | |
| WHERE bt.batch_id = '$escaped_batch' AND t.status IN ('complete', 'deployed', 'merged'); | |
| ") | |
| failed_count=$(db "$SUPERVISOR_DB" " | |
| SELECT count(*) FROM batch_tasks bt JOIN tasks t ON bt.task_id = t.id | |
| WHERE bt.batch_id = '$escaped_batch' AND t.status IN ('failed', 'blocked'); | |
| ") | |
| local stats | |
| stats=$(db -separator '|' "$SUPERVISOR_DB" "\n SELECT\n COUNT(*),\n SUM(CASE WHEN status IN ('complete', 'deployed', 'merged') THEN 1 ELSE 0 END),\n SUM(CASE WHEN status IN ('failed', 'blocked') THEN 1 ELSE 0 END)\n FROM tasks\n WHERE id IN (SELECT task_id FROM batch_tasks WHERE batch_id = '$escaped_batch');\n ") | |
| IFS='|' read -r total_tasks complete_count failed_count <<< "${stats:-0|0|0}" |
| batch_release_flag=$(db "$SUPERVISOR_DB" "SELECT release_on_complete FROM batches WHERE id = '$escaped_batch';" 2>/dev/null || echo "0") | ||
| if [[ "$batch_release_flag" -eq 1 ]]; then | ||
| local batch_release_type | ||
| batch_release_type=$(db "$SUPERVISOR_DB" "SELECT release_type FROM batches WHERE id = '$escaped_batch';" 2>/dev/null || echo "patch") |
There was a problem hiding this comment.
These two consecutive database queries to fetch release_on_complete and release_type can be combined into a single, more efficient query. This reduces database overhead. Consider one of two approaches:
- Fetch both columns at once and check the flag in bash:
local flag type
IFS='|' read -r flag type <<< "$(db ... 'SELECT release_on_complete, release_type ...')"
if [[ "$flag" -eq 1 ]]; then
# use type
fi- Combine the check into the
WHEREclause:
local type
type=$(db ... 'SELECT release_type FROM ... WHERE ... AND release_on_complete = 1;')
if [[ -n "$type" ]]; then
# use type
fi
1 participant
Summary
release_on_completeflag andrelease_typeto supervisor batches, enabling automaticversion-manager.sh releasewhen all tasks in a batch reach terminal statescmd_releasecommand for manual trigger, enable/disable, and dry-run supportChanges
Schema (
supervisor-helper.sh)batches.release_on_complete(INTEGER, default 0) - flag to enable auto-releasebatches.release_type(TEXT, default 'patch', CHECK major|minor|patch) - release bump typeNew Functions
trigger_batch_release()- Pulls main, runsversion-manager.sh release --skip-preflight, stores success/failure in memory, sends notifications. Non-blocking on failure.cmd_release()- Manual release trigger with--enable/--disable/--dry-run/--typeoptionsIntegration Points
check_batch_completion()- Checksrelease_on_completeflag after batch completes, triggers release if enabledcmd_batch()- New--release-on-completeand--release-typeflagsUsage Examples
Testing
--release-on-completeflag verifiedTask Reference
t128.10- Automatic release at batch milestones (blocked-by: t128.8, now complete)