ci: add goreleaser

[MeteorsLiu]

No description provided.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fennoai]

Review: ci: add goreleaser

This PR adds a tag-triggered GoReleaser release pipeline. The setup is clean and follows standard conventions — fetch-depth: 0 for changelog access, minimal contents: write permission, CGO_ENABLED=0 + mod_timestamp for reproducible static builds, and checksum generation. A few points worth addressing before merge; see inline comments plus the notes below.

Main finding (inline): the explicit ldflags in .goreleaser.yaml fully replaces GoReleaser's defaults, dropping version/commit/date injection. Worth confirming whether llar embeds a version.

Supply chain (inline): actions are pinned to mutable major tags rather than commit SHAs.

Additional non-blocking notes

• Job-level permissions (release.yml:8-9): permissions: contents: write is correctly scoped and required by GoReleaser. As defense-in-depth, consider moving it under the release job so only that job receives the write-scoped token — prevents scope creep if more jobs are added later.
• Go version source (release.yml:22): go-version: 1.24.x floats to the latest 1.24 patch. Since this project depends on internal linkname compatibility (-checklinkname=0), go-version-file: go.mod would give a single source of truth and reduce drift risk. Minor.
• Platform coverage (.goreleaser.yaml:11-16): only darwin/linux are built. If omitting Windows is intentional, no change needed — flagging only to confirm it's deliberate. If Windows is added later, a zip format_overrides for Windows is the usual convention.

No performance concerns found. LICENSE and README.md (referenced in the archive) both exist at the repo root.

[fennoai]

Specifying ldflags explicitly overrides GoReleaser's defaults rather than merging with them. The defaults include version injection:

-s -w -X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}} -X main.builtBy=goreleaser

As written, released binaries will lose version/commit/date injection, so a llar version/--version would report empty defaults. If ./cmd/llar embeds a version via -X, add those flags back:

ldflags:
  - -s -w -checklinkname=0
  - -X main.version={{ .Version }}
  - -X main.commit={{ .Commit }}
  - -X main.date={{ .Date }}

(Adjust the main.* variable paths to match the actual package/vars.) If llar genuinely doesn't inject a version, this is fine as-is — worth confirming.

[fennoai]

This third-party action (and actions/checkout@v4, actions/setup-go@v5) is pinned to a mutable major tag rather than an immutable commit SHA. A re-pointed tag on the action repo could run arbitrary code in this job, which holds contents: write and GITHUB_TOKEN. GitHub's hardening guidance recommends pinning to a full commit SHA, e.g.:

uses: goreleaser/goreleaser-action@<40-char-sha> # v7.x.x

Pinning the third-party goreleaser-action is the highest priority; pinning all of them is best practice.