Add reusable goreleaser-release workflow#35
Conversation
Adds a workflow_call-only workflow that runs GoReleaser against a caller repo. Generalises the standalone goreleaser.yml currently used in seictl into a maintained, versioned uci primitive that any sei-protocol repo can call. Inputs cover the variation we already see across consumers: - go-version / go-version-file (mutually exclusive) - goreleaser-version, args, working-directory - ref, checkout-latest-tag (workflow_run pattern) - submodules, fetch-depth, runs-on - prebuild-script for repo-specific system deps Token defaults to github.token; an UCI_GITHUB_TOKEN secret may override.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 2a19a88. Configure here.
| uses: actions/setup-go@v6 | ||
| with: | ||
| go-version: ${{ inputs.go-version }} | ||
| go-version-file: ${{ inputs.go-version-file }} |
There was a problem hiding this comment.
setup-go ignores working-directory for Go version auto-detection
Low Severity
When a caller sets working-directory to a subdirectory (e.g. for a monorepo) but omits both go-version and go-version-file, the setup-go step will look for go.mod in the repository root — not in the working-directory. The prebuild script and GoReleaser steps both honour working-directory, but setup-go does not, so Go version auto-detection silently fails to find the module file in the subdirectory.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 2a19a88. Configure here.
1 participant
Adds a `workflow_call`-only `.github/workflows/goreleaser-release.yml` that runs GoReleaser against a caller repo. Generalises the standalone `goreleaser.yml` currently used in seictl into a maintained, versioned uci primitive any sei-protocol repo can call.
Inputs cover the variation we see across consumers: `go-version` / `go-version-file`, `goreleaser-version`, `args`, `working-directory`, `ref`, `checkout-latest-tag`, `submodules`, `fetch-depth`, `runs-on`, `prebuild-script`. Token defaults to `github.token`; an `UCI_GITHUB_TOKEN` secret may override.
Refs PLT-41.
Note
Medium Risk
Moderate risk because it introduces a new release-publishing workflow with
contents: writepermissions and configurable refs/tags, which could affect how releases are produced if misused or misconfigured.Overview
Introduces a new reusable GitHub Actions workflow,
.github/workflows/goreleaser-release.yml, intended to be invoked viaworkflow_callto publish releases using GoReleaser.The workflow is parameterized for Go/GoReleaser versions, args, working directory, checkout ref/tag behavior (including an optional "checkout latest tag" step), submodules, fetch depth, runner selection, and an optional prebuild script; it publishes using
contents: writeand supports overriding the release token viaUCI_GITHUB_TOKEN(defaulting togithub.token).Reviewed by Cursor Bugbot for commit 2a19a88. Bugbot is set up for automated code reviews on this repo. Configure here.