ci: add scheduled auto-release workflow - #975
Conversation
Adds a GitHub Actions workflow that runs every 4 hours (and on workflow_dispatch) to check for releasable changes on main. It scans commits since the last semver tag for conventional commit prefixes: - If any feat commits exist → minor bump - If only fix commits exist → patch bump - If only chore/ci/docs/test → skip, no release The workflow pushes an annotated tag which triggers the existing release.yml + GoReleaser pipeline. The tag body contains a grouped summary of feat and fix commits. Requires an AUTO_RELEASE_TOKEN secret (fine-grained PAT with contents:write) because tags pushed by the default GITHUB_TOKEN do not trigger other workflows. Breaking changes bump minor while pre-1.0, with a comment block explaining how to shift to major bumps at 1.0. Partial-fix: #710 Assisted-by: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Ralph Bean <rbean@redhat.com>
|
fullsend review is working on this — view logs |
Site previewPreview: https://fb167fbf-site.fullsend-ai.workers.dev Commit: |
Review: #975Head SHA: 8e9e682 SummaryThis PR adds a well-structured scheduled auto-release workflow that scans conventional commits since the last semver tag, computes the appropriate version bump, and pushes an annotated tag to trigger the existing GoReleaser pipeline. The implementation is clean, correctly scoped as a partial fix for #710, and follows repo conventions. No critical or high findings — the notes below are minor robustness improvements worth considering. FindingsMedium
Low
Info
FooterOutcome: comment-only |
|
I'm not convinced, our main was broken for some time, and today I can't say that main is in a good state for people to use. Auto-releasing just will create noise under these circumstances. |
|
Ack, dropping this. Continue conversation at #710 (comment) |
…ard examples The guide taught pi as a 350-line parallel walkthrough (hand-rolled pi-hello harness, own config/profile/policy) written before the runtime became a per-run choice (#6526) and before the fleet repo carried the pi plumbing (agents#965/#975). Now there is one flow: the standard fleet examples, plus a "Choosing the runtime" subsection with --runtime pi on the same commands, the override precedence table (both runtimes), the verbatim output of a verified run (fullsend main @ 89bf3b8 against agents main @ 299f264 on macOS and Fedora — harness-default values print bare, overrides carry their source), Gemini-on-Vertex selection by model name, and a compact pi-notes list (build the CLI from main until a release ships pi; image 0.37+ and the exit-127 preflight symptom; review/retro single-context; FULLSEND_PI_PROVIDER and the bash allowlist; fail-closed hooks; --debug='*' and pi-debug.log). The pi platform notes fold into the existing Platform notes as one bullet per OS, and docs/runtimes.md points at the new anchor. Closes #6539 Assisted-by: Claude (code) Signed-off-by: Wayne Sun <gsun@redhat.com>
2 participants
Summary
.github/workflows/auto-release.yml— runs every 4 hours + onworkflow_dispatchfeat:andfix:prefixes using conventional commitschore/ci/docs/testcommits are presentfeat→ minor,fix→ patch, breaking → minor (pre-1.0)release.yml→ GoReleaser pipelineSetup required
A repo secret
AUTO_RELEASE_TOKENmust be created — a fine-grained PAT withcontents: writeon this repo. The defaultGITHUB_TOKENcan't be used because tags it pushes don't trigger other workflows (GitHub anti-cascade rule).Test plan
AUTO_RELEASE_TOKENsecretworkflow_dispatchrun with feat/fix commits since last tag → verify tag is pushed and release.yml triggersPartial-fix: #710
🤖 Generated with Claude Code