Why: Version bumps were happening but tags/releases weren't being created Impact: - After version bump PRs merge, tags and releases will be created automatically - commit-openagents command now analyzes repo health before commits - Detects missing releases, stale branches, and workflow issues Changes: - New workflow: create-release.yml (auto-creates tags & releases) - Workflow audit: WORKFLOW_AUDIT.md (complete documentation) - Enhanced: commit-openagents command with smart repo analysis Testing: Will manually trigger workflow to create v0.5.0 release
156 lines
5 KiB
Markdown
156 lines
5 KiB
Markdown
# Workflow Audit Report
|
|
|
|
**Date:** 2025-12-18
|
|
**Status:** ✅ Completed
|
|
|
|
## Summary
|
|
|
|
Comprehensive audit of GitHub Actions workflows to identify issues and streamline automation.
|
|
|
|
## Key Findings
|
|
|
|
### 🔴 Critical Issue: Missing Tags & Releases
|
|
|
|
**Problem:** Version bumps were happening (VERSION file at 0.5.0) but no git tags or GitHub releases were being created.
|
|
|
|
**Root Cause:** The `post-merge-pr.yml` workflow creates PRs for version bumps but doesn't create tags/releases. The disabled `post-merge.yml.disabled` had this functionality but was disabled to avoid direct pushes to main.
|
|
|
|
**Solution:** Created new `create-release.yml` workflow that:
|
|
- Detects when version bump PRs are merged (by checking for `version-bump` label)
|
|
- Creates git tags automatically
|
|
- Creates GitHub releases with CHANGELOG notes
|
|
- Supports manual triggering for backfilling missing releases
|
|
|
|
### ✅ Working Well
|
|
|
|
1. **PR Checks** (`pr-checks.yml`)
|
|
- Validates conventional commit format
|
|
- Runs build & validation
|
|
- Clear feedback to contributors
|
|
- **No changes needed**
|
|
|
|
2. **Registry Workflows**
|
|
- `validate-registry.yml` - Validates on PRs, handles forks gracefully
|
|
- `update-registry.yml` - Auto-updates registry on main
|
|
- **Both working great, no changes needed**
|
|
|
|
3. **Version Bump Workflow** (`post-merge-pr.yml`)
|
|
- Creates PRs for version bumps
|
|
- Updates VERSION, package.json, CHANGELOG.md
|
|
- Good loop prevention
|
|
- **Working well, just needed tag/release creation added**
|
|
|
|
### ⚠️ Potentially Overkill
|
|
|
|
**Docs Sync** (`sync-docs.yml`)
|
|
- Creates GitHub issues for OpenCode to process
|
|
- Creates branches and waits for manual PR creation
|
|
- May be more complex than needed
|
|
- **Recommendation:** Consider simplifying or making optional
|
|
|
|
## Changes Made
|
|
|
|
### 1. New Workflow: `create-release.yml`
|
|
|
|
**Purpose:** Automatically create git tags and GitHub releases after version bump PRs are merged.
|
|
|
|
**Features:**
|
|
- Detects version bump PR merges by checking for `version-bump` label
|
|
- Reads version from VERSION file
|
|
- Creates git tag (e.g., `v0.5.0`)
|
|
- Extracts release notes from CHANGELOG.md
|
|
- Creates GitHub release with notes
|
|
- Idempotent - checks if tag/release already exists
|
|
- Manual trigger support for backfilling
|
|
|
|
**Workflow:**
|
|
```
|
|
Version Bump PR Merged → Detect Label → Read VERSION → Create Tag → Create Release
|
|
```
|
|
|
|
### 2. Documentation
|
|
|
|
Created this audit report documenting:
|
|
- Current workflow state
|
|
- Issues found
|
|
- Solutions implemented
|
|
- Recommendations for future improvements
|
|
|
|
## Workflow Inventory
|
|
|
|
| Workflow | Status | Purpose | Changes |
|
|
|----------|--------|---------|---------|
|
|
| `create-release.yml` | ✅ NEW | Create tags & releases | New workflow |
|
|
| `post-merge-pr.yml` | ✅ Active | Version bump PRs | No changes |
|
|
| `post-merge.yml.disabled` | ❌ Disabled | Old direct push approach | Can be deleted |
|
|
| `pr-checks.yml` | ✅ Active | PR validation | No changes |
|
|
| `validate-registry.yml` | ✅ Active | Registry validation on PRs | No changes |
|
|
| `update-registry.yml` | ✅ Active | Auto-update registry | No changes |
|
|
| `sync-docs.yml` | ✅ Active | Sync docs via OpenCode | No changes |
|
|
| `validate-test-suites.yml` | ✅ Active | Validate test YAML | No changes |
|
|
|
|
## Next Steps
|
|
|
|
### Immediate
|
|
|
|
1. ✅ Create `create-release.yml` workflow
|
|
2. ⏳ Commit and push to trigger workflow
|
|
3. ⏳ Manually trigger workflow to create missing releases:
|
|
- v0.4.0 (if needed)
|
|
- v0.5.0
|
|
|
|
### Future Improvements (Optional)
|
|
|
|
1. **Simplify Docs Sync**
|
|
- Consider direct updates instead of issue-based approach
|
|
- Or make it manual-trigger only
|
|
|
|
2. **Cleanup**
|
|
- Delete `post-merge.yml.disabled`
|
|
- Clean up stale automation branches
|
|
- Archive old workflow documentation
|
|
|
|
3. **Documentation**
|
|
- Add workflow documentation to README
|
|
- Create troubleshooting guide
|
|
- Document manual release process
|
|
|
|
## Testing Plan
|
|
|
|
1. **Test New Workflow:**
|
|
- Manually trigger `create-release.yml` with version 0.5.0
|
|
- Verify tag creation
|
|
- Verify release creation
|
|
- Check release notes formatting
|
|
|
|
2. **Test Automatic Trigger:**
|
|
- Wait for next version bump PR to merge
|
|
- Verify workflow triggers automatically
|
|
- Verify tag and release created
|
|
|
|
## Recommendations
|
|
|
|
### Keep Simple
|
|
|
|
The current PR-based approach is working well. The new `create-release.yml` workflow completes the automation without adding complexity.
|
|
|
|
### Avoid Over-Engineering
|
|
|
|
- Don't add more automation unless there's a clear pain point
|
|
- Keep workflows focused and single-purpose
|
|
- Prefer manual triggers for infrequent operations
|
|
|
|
### Monitor & Iterate
|
|
|
|
- Watch for workflow failures
|
|
- Gather feedback from contributors
|
|
- Adjust based on actual usage patterns
|
|
|
|
## Conclusion
|
|
|
|
✅ **Critical issue fixed:** Tags and releases will now be created automatically
|
|
✅ **Minimal changes:** Only added one new workflow
|
|
✅ **Existing workflows:** All working well, no changes needed
|
|
✅ **Simple & maintainable:** Easy to understand and debug
|
|
|
|
The workflow system is now complete and should handle version management automatically while keeping the PR-based approval process you prefer.
|