Skip to content

ci(release): align release.yml with current CI — Go 1.25 + Windows MSYS2#19

Merged
shahid-io merged 1 commit into
mainfrom
ci/fix-release-workflow
May 10, 2026
Merged

ci(release): align release.yml with current CI — Go 1.25 + Windows MSYS2#19
shahid-io merged 1 commit into
mainfrom
ci/fix-release-workflow

Conversation

@shahid-io

Copy link
Copy Markdown
Owner

Summary

Pre-tag fix for two issues in `release.yml` that would block a v0.2.0 release:

  1. Go 1.22 vs go.mod's 1.25 — workflow was pinned when v0.1.0 was cut; build would fail with toolchain error. Bumped both setup-go calls to 1.25.
  2. Windows builds — same `sqlite3.h not found` issue we fixed in `ci.yml`. Mirror the fix: `msys2/setup-msys2` with the mingw-w64 toolchain, run GoReleaser through `shell: msys2 {0}`.

Why directly to main

This is a CI-only change. No production code touches. Merging through develop would force a release-merge-back-to-develop sync we don't need. Filing directly to main with the standard PR + status-check gates.

Implementation note

GoReleaser-action is used in `install-only: true` mode now — it just drops the binary, then we invoke `goreleaser release --split --clean` ourselves. This lets Windows use `shell: msys2 {0}` for the GoReleaser run without forking the action's logic.

After this lands

Tag `v0.2.0` on main → release workflow triggers → cross-platform binaries land on the GitHub Releases page → `go install …@latest` finally points at current code.

Test plan

  • No code paths change
  • CI green on this PR
  • Verify by tagging v0.2.0 after merge — that's the actual proof. If the release workflow fails on a specific OS, iterate.

Two issues that would block the next tag-triggered release:

1. Go 1.22 vs go.mod's 1.25 — the workflow was pinned to an older Go
   when v0.1.0 was cut. Bump both setup-go calls to 1.25.

2. Windows release builds had the same sqlite3.h-not-found problem we
   just fixed in ci.yml. Mirror the fix: msys2/setup-msys2 with the
   mingw-w64-x86_64 toolchain, run GoReleaser through `shell: msys2`
   so gcc finds /mingw64/include from its native shell context.

Restructured the GoReleaser invocation: the action is used in
`install-only: true` mode (just drops the binary), then we run
`goreleaser release --split --clean` ourselves with the appropriate
shell per OS. This gives Windows the msys2 shell without forking
the action's invocation logic.

Linux arm64 cross-compile setup (gcc-aarch64-linux-gnu) is unchanged
— it was already correct and continues to work for the ubuntu-latest
runner that builds both amd64 and arm64 Linux binaries.
@shahid-io
shahid-io merged commit e1bc212 into main May 10, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant