chore(release): wire goreleaser to a tag-triggered workflow#54
Conversation
Wires .goreleaser.yml to a tag-triggered GitHub Actions workflow so `v*` pushes publish a release. Modernizes the existing config to goreleaser v2 (adds `version: 2`, switches `format` to `formats`) to match the pinned action. Closes #53
📝 WalkthroughWalkthroughThis PR enables automated binary releases for a7 by adding a GitHub Actions release workflow and updating the GoReleaser configuration to v2 format. The workflow triggers on version tag pushes and orchestrates GoReleaser to build and publish releases across Linux, Darwin, and Windows platforms. ChangesRelease Automation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/release.yml (2)
16-18: ⚡ Quick winAdd
persist-credentials: falseto the checkout step.The static analysis tool flags that credentials may persist through GitHub Actions artifacts when
persist-credentialsis not explicitly set tofalse. This is a security hardening best practice to prevent credential leakage.🔒 Proposed security hardening
- uses: actions/checkout@v4 with: fetch-depth: 0 + persist-credentials: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 16 - 18, The checkout step using actions/checkout@v4 currently omits the persist-credentials option; update the checkout configuration (the actions/checkout@v4 step) to include persist-credentials: false alongside existing keys (e.g., fetch-depth: 0) so credentials are not persisted to the workspace or artifacts, ensuring the workflow uses the hardened setting.
16-16: ⚡ Quick winConsider pinning actions to commit SHAs.
The static analysis tool flags that actions are referenced by tags rather than commit SHAs and notes this is "required by blanket policy." Pinning to SHAs prevents supply chain attacks where tags could be moved to malicious code.
🔐 Example SHA pinning approach
You can find current commit SHAs for each action version and pin them:
- - uses: actions/checkout@v4 + - uses: actions/checkout@<sha> # v4 with: fetch-depth: 0 - - uses: actions/setup-go@v5 + - uses: actions/setup-go@<sha> # v5 with: go-version-file: go.mod - - uses: goreleaser/goreleaser-action@v6 + - uses: goreleaser/goreleaser-action@<sha> # v6Note: SHA pinning does increase maintenance burden as you'll need to update SHAs when updating action versions.
Also applies to: 20-20, 24-24
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml at line 16, The workflow currently references actions by tags (e.g., "uses: actions/checkout@v4") which should be pinned to commit SHAs to reduce supply-chain risk; update each "uses:" entry in .github/workflows/release.yml (including the actions/checkout entry and the other actions referenced by tags in this file) to the corresponding commit SHA for the desired release (replace the tag with the SHA value), ensuring you fetch the canonical SHA from the action's GitHub repo and commit the updated workflow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 16-18: The checkout step using actions/checkout@v4 currently omits
the persist-credentials option; update the checkout configuration (the
actions/checkout@v4 step) to include persist-credentials: false alongside
existing keys (e.g., fetch-depth: 0) so credentials are not persisted to the
workspace or artifacts, ensuring the workflow uses the hardened setting.
- Line 16: The workflow currently references actions by tags (e.g., "uses:
actions/checkout@v4") which should be pinned to commit SHAs to reduce
supply-chain risk; update each "uses:" entry in .github/workflows/release.yml
(including the actions/checkout entry and the other actions referenced by tags
in this file) to the corresponding commit SHA for the desired release (replace
the tag with the SHA value), ensuring you fetch the canonical SHA from the
action's GitHub repo and commit the updated workflow.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f6a18bcb-37bc-471c-96f8-d9d32f6b01a7
📒 Files selected for processing (2)
.github/workflows/release.yml.goreleaser.yml
There was a problem hiding this comment.
Pull request overview
This PR wires the existing GoReleaser configuration into GitHub Actions so that pushing a v* tag automatically builds and publishes cross-platform release assets to a GitHub Release. It also updates .goreleaser.yml to GoReleaser v2 config syntax to match the pinned goreleaser/goreleaser-action@v6.
Changes:
- Add a tag-triggered GitHub Actions workflow that runs
goreleaser release --cleanand publishes a GitHub Release. - Update
.goreleaser.ymltoversion: 2and migrate archiveformatkeys toformats.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
.goreleaser.yml |
Migrates config to GoReleaser v2 syntax (version: 2, format → formats) for archive generation. |
.github/workflows/release.yml |
Adds a workflow that runs on v* tags to execute GoReleaser and publish GitHub Release assets. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
.github/workflows/release.ymlthat runs goreleaser onv*tag push, publishing a GitHub Release with cross-platform archives and checksums..goreleaser.ymlto v2 syntax (version: 2,format→formats) so it works with the pinnedgoreleaser/goreleaser-action@v6(~> v2).No changes to Go code, so
internal/update/plumbing (asset name formata7_{version}_{os}_{arch}.{ext}) stays compatible with what the workflow will publish.Closes #53
Test plan
goreleaser checkagainst the updated config (run via Docker locally)v0.1.0-rc1after merge and confirm the workflow publishes assetsa7 updateend-to-end against the published rc releaseSummary by CodeRabbit