Add automated release workflow - #72
bootc-bot[bot] wants to merge 1 commit into
Conversation
bootc-bot
Bot
added
the
agent/workflow-edits-allowed
bootc-bot
Bot
added
the
agent/review-working
|
TODO followup to this ensure the drafter agent has e.g. a |
![bootc-bot[bot]](https://avatars.githubusercontent.com/u/202312630?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the full diff and file context. This implementation:
- Follows established workflow patterns (drafter.md, review.md, fix.md)
- Correctly integrates with the build system (aw.yml, ci.yml, justfile)
- Sets gh-aw version to v0.81.6, matching the min-version requirement
- Implements all requirements from issue #71 (weekly schedule, LLM-generated release notes, PR-based workflow requiring human approval)
- Handles edge cases appropriately (no changes, missing data)
- Has clear, detailed task instructions for the release agent
The missing lock file is appropriately documented in the PR description and will be generated by CI after merge or by running just compile locally.
Ready to merge.
bootc-bot
Bot
removed
agent/review-working
bootc-bot
Bot
added
agent/fix-working
|
Commit pushed:
|
bootc-bot
Bot
added
agent/review-working
There was a problem hiding this comment.
Reviewed the release workflow implementation. The workflow is well-structured, follows repository conventions, and correctly implements the requirements from issue #71. All configuration files are properly updated, the compiled lock file is valid, and the workflow includes appropriate edge case handling. Ready to merge.
bootc-bot
Bot
removed
agent/review-working
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
So this won't actually create the GH release though, just a branch? Does safe outputs support that?
| - [Documentation changes] | ||
|
|
||
| ## Commits | ||
| [List of commit references] |
There was a problem hiding this comment.
Hmm we probably want a deterministic skill/tool or recommendation for formatting of this
| - cron: '0 9 * * 1' | ||
| workflow_dispatch: | ||
|
|
||
| permissions: |
There was a problem hiding this comment.
(Do we need this stuff btw? doesn't the MCP server allow reads)
There was a problem hiding this comment.
Pull request overview
Adds a weekly agent intended to draft release PRs with AI-generated notes.
Changes:
- Adds scheduled/manual release workflow source and compiled output.
- Integrates release compilation and distribution.
- Pins gh-aw v0.86.2 and refreshes generated metadata.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/release.md |
Defines the release agent. |
.github/workflows/release.lock.yml |
Adds compiled workflow output. |
.github/workflows/ci.yml |
Compiles release workflow in CI. |
justfile |
Compiles release workflow locally. |
aw.yml |
Includes release workflow in distribution. |
.github/aw/gh-aw-version |
Pins gh-aw v0.86.2. |
.github/aw/actions-lock.json |
Refreshes action pins. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| create-pull-request: | ||
| max: 1 | ||
| branch-prefix: release/ |
|
|
||
| ## Your task | ||
|
|
||
| 1. **Determine the next version**: Read the git tags to find the latest release. |
| If no tags exist, use `v0.1.0` as the starting version. Otherwise, increment | ||
| the patch version (e.g., `v1.2.3` → `v1.2.4`). |
There was a problem hiding this comment.
Yes technically this is semver if there's semantic changes bump the minoir
| 4. **Create the release PR**: Use the `create-pull-request` safe-output to | ||
| create a PR with: | ||
| - **Title**: `Release <version>` (e.g., "Release v1.2.4") | ||
| - **Branch**: `release/<version>` (e.g., "release/v1.2.4") | ||
| - **Body**: The generated release notes in markdown format |
| 4. **Create the release PR**: Use the `create-pull-request` safe-output to | ||
| create a PR with: | ||
| - **Title**: `Release <version>` (e.g., "Release v1.2.4") | ||
| - **Branch**: `release/<version>` (e.g., "release/v1.2.4") |
| - **Title**: `Release <version>` (e.g., "Release v1.2.4") | ||
| - **Branch**: `release/<version>` (e.g., "release/v1.2.4") | ||
| - **Body**: The generated release notes in markdown format | ||
| - **Labels**: `release` |
| - Never push directly to the default branch | ||
| - Only create release PRs, not actual releases or tags |
| schedule: | ||
| # Weekly on Mondays at 9:00 UTC | ||
| - cron: '0 9 * * 1' |
bootc-bot
Bot
added
agent/fix-working
|
Commit pushed:
|
Fixed: GitHub Release CreationAddressed the review feedback from ChangesThe release workflow now implements a two-phase automated process:
Why This ApproachSafe-outputs doesn't support direct release creation, so the solution uses a standard GitHub Actions workflow (
The workflow documentation has been updated to clarify this two-phase process.
|
There was a problem hiding this comment.
Review Summary
I've reviewed the automated release workflow implementation. The code is well-structured, follows repository conventions, and correctly implements the requirements.
What I Checked
✅ Workflow structure: release.md follows established patterns from drafter.md and review.md
✅ Integration: Properly added to aw.yml, ci.yml, and justfile
✅ Lock file: release.lock.yml is present and compiled (122KB)
✅ Safe-outputs: Correctly configured with appropriate permissions and constraints
✅ Two-phase design: Release PR creation + publish-on-merge workflow is sound
✅ Edge cases: Handles no changes, missing data, and existing release PRs
✅ Label setup: Added release label to installation scripts
✅ Previous issues: The --verify-tag bug identified in earlier reviews has been fixed
✅ AI attribution: Includes "Assisted-by: AI" per CLAUDE.md requirements
Implementation Details
The workflow correctly:
- Uses GitHub's release notes generation API as a starting point
- Limits file modifications to RELEASE-NOTES.md only
- Requires human approval before merge (max: 1 PR)
- Uses
branch-prefix: release/which pairs correctly withpublish-release.yml's branch name extraction - Handles version detection and increment logic appropriately
The publish-release.yml workflow properly extracts the version from the branch name and creates the GitHub release when the PR merges.
Ready to merge.
bootc-bot
Bot
removed
agent/review-working
|
Made some changes/fixes to this locally and updated it. |
| @@ -0,0 +1,93 @@ | |||
| --- | |||
| description: | | |||
| Automated release agent. Runs weekly to create a release PR with | |||
There was a problem hiding this comment.
Sanity check, this workflow for now should only apply to this repository, we're not yet trying to have shared automated release workflows across the org (yet).
| noop: | ||
| missing-data: | ||
|
|
||
| timeout-minutes: 15 |
There was a problem hiding this comment.
That seems kind of unnecessary
| to check if a release PR is already open. If the count is non-zero, | ||
| use `noop` to report that a release PR is already open. | ||
|
|
||
| 2. **Fetch full history**: The checkout is shallow by default. Run |
There was a problem hiding this comment.
Huh, really? Kind of weird, can we just configure that in GH-AW deterministically?
There was a problem hiding this comment.
Checked; there's no frontmatter option for fetch depth. The compiler hardcodes fetch-depth: 1 in all compiled workflows (drafter, review, fix all have it too). The git fetch --unshallow --tags in the agent instructions is the workaround for now.
| `git fetch --unshallow --tags` so that all tags and commit history | ||
| are available. | ||
|
|
||
| 3. **Determine the next version**: Read the git tags to find the latest |
There was a problem hiding this comment.
I think we should script this and tell the agent to run the script.
| contains(github.event.pull_request.labels.*.name, 'release') && | ||
| startsWith(github.event.pull_request.head.ref, 'release/') | ||
| runs-on: ubuntu-latest | ||
| timeout-minutes: 10 |
bootc-bot
Bot
added
agent/review-working
There was a problem hiding this comment.
Review: Release Workflow Implementation
I've reviewed the release workflow implementation against the repository's code guidelines (CLAUDE.md, REVIEW.md).
Issue Found
.github/workflows/publish-release.yml:14 — Violates CLAUDE.md runner image guideline:
- Current:
runs-on: ubuntu-latest - Required:
runs-on: ubuntu-24.04
Per CLAUDE.md lines 69-77:
When adding or editing workflows, use a fixed runner image such as
ubuntu-24.04, notubuntu-latest.
What I Checked
✅ release.md workflow structure — Proper safe-outputs configuration with appropriate constraints (max: 1, branch-prefix, allowed-files)
✅ next-version.sh script — Follows shell best practices (set -euo pipefail, proper error handling)
✅ Label definitions — Added to both install-labels.yml and scripts/install-labels.js
✅ Compilation lists — Updated in ci.yml, aw.yml, and justfile
✅ Workflow logic — Correctly implements two-phase release process (PR creation → merge-triggered publish)
✅ Agent instructions — Clear, handles edge cases (existing PRs, missing data)
Required Change
Change line 14 in .github/workflows/publish-release.yml from ubuntu-latest to ubuntu-24.04.
bootc-bot
Bot
added
agent/fix-working
|
Commit pushed:
|
bootc-bot
Bot
added
agent/review-working
There was a problem hiding this comment.
Review Summary
I've reviewed the release workflow implementation. The structure is well-designed and integrates properly with the existing workflows, but there's a critical issue with the workflow instructions that will cause authentication failures when the agent executes them.
Issues Found
❌ Critical: Unauthenticated gh CLI Usage in release.md
Lines 45 and 59 instruct the agent to use gh CLI commands:
- Line 45:
gh pr list --label release --state open --json number --jq length - Line 59:
gh api repos/$GITHUB_REPOSITORY/releases/generate-notes ...
Problem: The gh CLI is not authenticated in gh-aw workflows. As documented in the system guidelines: "Do not use shell gh commands for GitHub API reads — gh is not authenticated."
The github-app configuration in safe-outputs only authenticates the safe-output tools (like create-pull-request), not the gh CLI itself.
Impact: When the release agent runs, these commands will fail with authentication errors, forcing the agent to work around the issue. This could result in:
- Workflow execution delays as the agent troubleshoots
- Different release note formatting than intended (if the agent generates notes manually)
- Potential workflow failure if the agent can't find an alternative
Required Fix
Update .github/workflows/release.md to use GitHub MCP tools instead of gh CLI:
Step 1 (line 44-47) should use the GitHub MCP tool list_pull_requests:
1. **Check for existing release PRs**: Before doing anything else, use the
GitHub MCP `list_pull_requests` tool with `labels: ["release"]` and
`state: "open"` to check if a release PR is already open. If any results
are returned, use `noop` to report that a release PR is already open.Step 4 (lines 56-66) should either:
- Document that the agent should use available GitHub MCP tools (
list_commits, etc.) to generate release notes manually, OR - Provide alternative instructions that don't rely on the GitHub API's generate-notes endpoint
Since there's no direct MCP equivalent for generate-notes, I recommend updating the instruction to:
4. **Generate release notes**: Use the GitHub MCP `list_commits` tool to fetch
commits between the last release and HEAD. Then analyze and categorize them
by type (Features, Bug Fixes, Documentation, Dependencies, Other), add a
brief summary at the top, and highlight any breaking changes.What Works Well
✅ Proper workflow structure with frontmatter, permissions, and safe-outputs configuration
✅ Integration with existing workflows (aw.yml, ci.yml, justfile)
✅ Label configuration added to both install-labels files
✅ The publish-release.yml workflow is correctly structured (uses standard GitHub Actions with authenticated gh via github.token)
✅ The next-version.sh script logic is sound
✅ Clear edge case handling (existing PRs, no changes, missing data)
✅ Already fixed the ubuntu-24.04 issue from earlier feedback
Minor Observations
- The
next-version.shscript lacks tests (REVIEW.md recommends tests for non-trivial logic), but this is acceptable for a simple utility script - Commit history includes an "Address review feedback" commit that could have been squashed per REVIEW.md guidelines, but since PRs are squashed on merge this doesn't affect the final history
Once the gh CLI issue is fixed, this will be a solid addition to the repository's automation capabilities.
bootc-bot
Bot
added
agent/fix-working
|
The automated fix loop has reached its iteration limit (3 commits) and automated fixing has stopped. A human needs to review this PR and either:
Important: Re-applying the Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
To allow these domains, add them to the network:
allowed:
- defaults
- "api.anthropic.com"See Network Configuration for more information.
|
bootc-bot
Bot
removed
the
agent/fix-working
f553348 to
02ce94b
Compare
Add a weekly release agent that creates release PRs with notes generated from git history, and a companion publish-release.yml that creates the GitHub release when the PR is merged. Version bumping is handled by scripts/next-version.sh (v0.x.0 minor releases per project policy). The agent is scoped to only modify RELEASE-NOTES.md via allowed-files. Addresses: #71 Assisted-by: AI Signed-off-by: gursewak1997 <gursmangat@gmail.com>
02ce94b to
c11e5f6
Compare
bootc-bot
Bot
added
agent/review-working
There was a problem hiding this comment.
Review Complete - Ready to Merge
I've reviewed the release automation workflow implementation against the repository's conventions and code quality guidelines.
What I Checked
Code Structure & Quality:
- ✅ Workflow structure follows established patterns (drafter.md, review.md, fix.md)
- ✅ Uses
ubuntu-24.04fixed runner (not ubuntu-latest) - ✅ Proper safe-outputs configuration with github-app credentials
- ✅ Shell script (
next-version.sh) usesset -euo pipefail, passes syntax check, under 50 lines - ✅ Label definitions added to all required locations
- ✅ Compilation lists updated in ci.yml, justfile, and aw.yml
- ✅ Lock file successfully generated (1870 lines)
Workflow Logic:
- ✅ Prevents duplicate release PRs with explicit check
- ✅ Properly scopes file modifications to RELEASE-NOTES.md only
- ✅ Handles edge cases (no changes, missing data) with noop/missing-data
- ✅ Requires human review before merge (no auto-merge)
- ✅ Companion
publish-release.ymlcorrectly extracts version and creates GitHub release
Conventions:
- ✅ Follows repository's agent workflow patterns
- ✅ Uses gh CLI commands consistently with other workflows (fix.md, queue-triage.md)
- ✅ Proper permissions configuration (contents: read + github-app auth)
Minor Notes
-
PR Description: The note about release.lock.yml not being included is outdated—the file is present with 1870 lines. This doesn't affect the code but might confuse readers.
-
Testing: Per REVIEW.md guidelines, manual testing should be documented. The PR description outlines a post-merge testing plan via workflow_dispatch, which is appropriate for workflow definitions that require being merged before they can be fully tested.
-
Version Script Edge Case:
next-version.shassumesv<major>.<minor>.<patch>format. If tags deviate from this pattern, the script may produce unexpected results. This is likely acceptable for this repository's versioning scheme.
Verdict
The implementation is solid, follows all important repository conventions, and is ready to merge. The workflow will function correctly as designed, and any remaining validation can happen through the post-merge testing plan described in the PR.
bootc-bot
Bot
removed
agent/review-working
Add a weekly release agent workflow and a companion publish-release.yml
that creates the GitHub release when the release PR is merged.
Changes
notes using GitHub's API, writes RELEASE-NOTES.md, and opens a release PR
with the
releaselabel is mergedreleaselabelreleasein compilationTesting
Workflow definitions require being merged before they can run. After merge:
Addresses: #71
Assisted-by: AI