Add automated release workflow - #72
Conversation
Implements a weekly release agent that creates release PRs with LLM-generated release notes. The workflow triggers on schedule (Monday 9:00 UTC) or manual dispatch, analyzes git history since the last release, generates structured release notes, and creates a PR for human review and approval. Changes: - Add .github/workflows/release.md workflow definition - Update aw.yml to include release workflow - Update ci.yml and justfile to compile release workflow - Set gh-aw-version to v0.81.6 (was empty) The release.lock.yml file will be generated when this PR is merged and the CI workflow runs. Assisted-by: AI Addresses: #71
|
TODO followup to this ensure the drafter agent has e.g. a |
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.
The initial PR was missing the compiled lock file for release.md. Additionally, the gh-aw-version was set to v0.81.6, but the existing lock files were compiled with v0.86.2 which uses different syntax. Changes: - Add .github/workflows/release.lock.yml (compiled from release.md) - Update gh-aw-version from v0.81.6 to v0.86.2 to match existing locks - Update actions-lock.json as part of recompilation Assisted-by: AI
|
Commit pushed:
|
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.
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.
| github-app: | ||
| client-id: ${{ vars.GH_AW_APP_CLIENT_ID }} | ||
| private-key: ${{ secrets.GH_AW_APP_PRIVATE_KEY }} | ||
| permissions: | ||
| workflows: write |
| 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`). |
| 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' |
Addresses review feedback about creating actual releases. The release workflow now works as a two-phase process: 1. Phase 1 (release.md): Creates a release PR with LLM-generated notes 2. Phase 2 (publish-release.yml): Creates the GitHub release when merged Changes: - Add publish-release.yml workflow to create releases on PR merge - Update release.md to document the two-phase process - Clarify that safe-outputs doesn't support direct release creation - Recompile release.lock.yml with updated workflow definition Assisted-by: AI
|
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.
|
e970120
There was a problem hiding this comment.
Review Summary
I've reviewed the release automation workflow. The overall design is sound and follows repository patterns well, but there's one critical bug that will cause the publish workflow to fail.
Critical Issue
File: .github/workflows/publish-release.yml line 40
gh release create "$version" \
--repo "${{ github.repository }}" \
--title "Release $version" \
--notes "$pr_body" \
--verify-tagThe --verify-tag flag causes gh release create to abort if the tag doesn't already exist. Since release PRs are regular PRs (not tag-based), the tag won't exist when this workflow runs, causing it to fail.
Fix: Remove --verify-tag to allow gh release create to create both the tag and release automatically:
gh release create "$version" \
--repo "${{ github.repository }}" \
--title "Release $version" \
--notes "$pr_body"This aligns with the documented behavior in release.md:127 which states the workflow "Creates a git tag for the release."
Minor Issue
File: .github/aw/actions-lock.json
The removal of github/gh-aw-actions/setup-cli@v0.86.2 isn't explained. If this is intentional cleanup, it's fine—but unexpected changes to lock files should typically be explained.
What I Checked
✅ Workflow structure follows repository patterns (compared to drafter.md, fix.md)
✅ Safe-outputs configuration is appropriate (permissions, limits, branch prefix)
✅ Release agent instructions are clear and comprehensive
✅ Edge case handling (no changes, missing data) is covered
✅ Configuration updates (aw.yml, ci.yml, justfile) are correct
✅ Two-phase release process design is sound
The workflow design is well thought out and matches the repository's patterns. Once the --verify-tag bug is fixed, this will be ready to merge.
Automated Fix Loop: Iteration Limit ReachedThe automated fix loop has reached its iteration limit (3 commits). Automated fixing has stopped to prevent excessive automated iterations. What this means:
Next steps for humans:
Important: Re-applying the
|
This PR implements a release agent workflow as requested in issue #71.
Summary
Adds a new weekly release workflow that creates release PRs with LLM-generated release notes. The workflow is designed to run automatically every Monday at 9:00 UTC or can be triggered manually via workflow_dispatch.
Changes
New Files
.github/workflows/release.md: Release agent workflow definitionModified Files
aw.yml: Added release.md to the includes list.github/workflows/ci.yml: Addedreleaseto the compilation listjustfile: Addedreleaseto the compilation list.github/aw/gh-aw-version: Set tov0.81.6(was empty)Workflow Features
The release agent:
Validation
Note: The
release.lock.ymlfile is not included in this PR because the gh CLI is not authenticated in the agent environment. The lock file will be generated when:just setup && just compilelocally, ORThe workflow structure has been validated against existing workflows (drafter.md, review.md, fix.md) to ensure consistency with the repository's patterns.
Testing
To test this workflow after merge:
releaselabel exists in the repositoryAssisted-by: AI
Addresses: #71
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
just.systemsTo allow these domains, add them to the
network.allowedlist in your workflow frontmatter:See Network Configuration for more information.