ci: build release binaries with goreleaser - #55
Conversation
|
Warning Review limit reached
Next review available in: 43 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds release-please metadata, GoReleaser configuration for cross-platform Estimated code review effort: 2 (Simple) | ~10 minutes ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
513c2fc to
96727e9
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 436b45fe-353f-4cf1-84eb-22912b846d74
📒 Files selected for processing (2)
.github/workflows/release.yml.goreleaser.yaml
96727e9 to
7dc04a1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 666776f3-aed1-47c0-a64e-a52f4996628e
📒 Files selected for processing (4)
.github/workflows/release.yml.goreleaser.yaml.release-please-manifest.jsonrelease-please-config.json
Six targets, matching the cross-compile job: linux, darwin and windows on amd64 and arm64. CGO_ENABLED=0 costs nothing — go-keyring shells out to `security` on macOS and talks D-Bus on Linux, neither of which needs cgo. The tag drives everything: release-please creates it and the release, then `mode: append` uploads the archives into that release without touching the notes it wrote. beep boop
goreleaser has no attestation of its own — the documented route is actions/attest after it runs. subject-checksums attests every file listed in checksums.txt, so all six archives are covered without naming them. Verify with `gh attestation verify --owner Flagsmith <file>`. beep boop
GitHub will not let a prerelease be Latest ("Drafts and prereleases cannot be
set as latest"), and the prerelease flag is not separable from the -beta
version: release-please derives it from the version itself. So clear the flag
after publishing instead. The condition takes itself out of service once 2.0.0
ships, since a stable release becomes Latest on its own.
beep boop
`mode` governs the release notes, not the artifacts — those upload either way. append happens to be harmless while the changelog is disabled, since our notes are empty, but keep-existing says what we mean and stays correct if anyone enables the changelog later. beep boop
.Tag is the last release tag even under --snapshot, so every snapshot stamped v1.1.0 and IsRelease then pinned doc URLs to a tag the build has nothing to do with. Snapshots now stamp the snapshot version, v1.1.0-SNAPSHOT-090323e. Stamping the literal `dev` would not have worked: resolve() treats dev as unstamped and replaces it from debug.ReadBuildInfo, which yields a Go pseudo-version — correct, but it would show up in --version and the User-Agent as v1.1.1-0.20260730115333-090323eb8be5+dirty. beep boop
e0524b2 to
ab10f29
Compare
3 participants
Contributes to #45
Verified locally
goreleaser checkclean.goreleaser release --snapshot --clean --skip=publishbuilt all six targets and packaged them; archives containflagsmith,LICENSE,README.md.flagsmith version v1.1.0— the stamp resolves through theinternal/version.Versionldflags path.Also attests the archives:
actions/attestwithsubject-checksumscovers every file listed inchecksums.txt. Verify withgh attestation verify --owner Flagsmith <file>.