fix(release): use direct Go build instead of build action

[Snider]

Summary

• The build action only supports wails2/cpp stacks and defaults to wails2 for unknown projects
• Core is a pure Go CLI with no frontend, so it needs direct go build

Changes

• Replace host-uk/build@dev with direct Go build steps
• Build separate darwin/amd64 and darwin/arm64 (instead of darwin/universal which requires lipo)
• Set CGO_ENABLED=0 for static binaries
• Inject version via -ldflags -X main.Version=...

Context

This unblocks the core CLI release. Once this is merged, we can tag a version and the release workflow will build binaries for all platforms.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Enhanced the automated build and release process to compile the CLI for multiple platforms with improved artifact organization and distribution.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[coderabbitai]

📝 Walkthrough

Walkthrough

The release workflow is restructured to implement a Go-focused build process using explicit OS/architecture matrix pairs, with automated setup, compilation, artifact naming, and release handling through GitHub Actions.

Changes

Cohort / File(s)	Summary
Release Workflow .github/workflows/release.yml	Updated build matrix to use explicit goos/goarch pairs with platform-specific file extensions. Added Setup Go action with caching, introduced Build CLI step that compiles binaries to dist/core-<goos>-<goarch><ext> with version embedding, replaced artifact upload with new naming scheme, and reorganized release step to download and utilize artifacts.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• feat: CI improvements and release channels #266: Modifies the same .github/workflows/release.yml file with related changes to build matrix and artifact handling in the release workflow.

Poem

🐰 A workflow hops with Go so bright,
Matrix pairs arranged just right,
Artifacts compiled, named with care,
Multi-platforms everywhere!
Release pipelines skip and leap! 🎉

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: replacing a generic build action with direct Go build steps in the release workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/release-go-build

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/release.yml (1)

75-79: ⚠️ Potential issue | 🟡 Minor

Silencing errors may mask missing artifacts.

The 2>/dev/null || true pattern suppresses all errors, including cases where no artifacts were downloaded. If the build job fails partially or artifacts are missing, this step would succeed silently, potentially creating a release with missing binaries.

Consider adding validation:

🛡️ Proposed fix to validate artifacts exist

       - name: Prepare release files
         run: |
           mkdir -p release
-          cp dist/* release/ 2>/dev/null || true
+          cp dist/* release/
+          if [ -z "$(ls -A release/)" ]; then
+            echo "Error: No release artifacts found"
+            exit 1
+          fi
           ls -la release/

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

40-44: Consider extracting Go version to a single source of truth.

Hardcoding go-version: '1.23' works, but maintaining version consistency becomes easier if the version is derived from go.mod or a repository variable. The setup-go action supports reading from go.mod:

go-version-file: 'go.mod'

This ensures the workflow always uses the same Go version declared in the project.