Fix version display in release binaries to show actual release tag instead of "dev"

[Copilot]

Problem

When users install the gh-aw extension via gh extension install githubnext/gh-aw, the downloaded binaries display version as "dev" instead of the actual release version:

$ gh aw version
ℹ gh aw version dev
ℹ GitHub Agentic Workflows CLI from GitHub Next

This occurs because the release workflow uses cli/gh-extension-precompile@v2, which builds binaries without setting the version variable through Go's -ldflags mechanism.

Solution

This PR implements a custom build script that properly embeds the release version into all binaries during the GitHub Actions release process.

Changes

1. Custom Build Script (scripts/build-release.sh)

• Takes the release version as a required argument (automatically provided by gh-extension-precompile)
• Builds binaries for all 12 supported platforms (darwin, linux, freebsd, windows across multiple architectures)
• Embeds version using -ldflags="-s -w -X main.version=${VERSION}"
• Maintains consistency with local make build behavior

2. Updated Release Workflow (.github/workflows/release.yml)

- go_build_options: ./cmd/gh-aw
+ build_script_override: scripts/build-release.sh

3. Comprehensive Tests

• Go tests (cmd/gh-aw/version_test.go) verify version can be overridden at build time
• Bash tests (scripts/test-build-release.sh) validate the complete build script functionality
• All tests ensure version is properly set and is not "dev"

Verification

Manual testing with a test version demonstrates the fix:

$ ./scripts/build-release.sh v0.99.99-test
Building binaries with version: v0.99.99-test
...
Build complete.

$ ./dist/linux-amd64 version
ℹ gh aw version v0.99.99-test
ℹ GitHub Agentic Workflows CLI from GitHub Next

Impact

After this change is merged and included in the next release, users installing via gh extension install githubnext/gh-aw will see the correct release version (e.g., v0.22.5) instead of "dev", making it easier to:

• Verify the installed version
• Debug issues with specific releases
• Provide accurate version information in bug reports

All existing tests pass, and the solution uses minimal changes to achieve the desired behavior.

[!WARNING]

Original prompt

Validate that the gh aw extension install through gh extension install aw has the proper version (latest release) and not dev.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[pelikhan]

/scout is there an option in cli/gh-extension-precompile@v2 to set the version?

Agentic Scout triggered by this comment

[pelikhan]

@copilot is it simpler to change go_build_options and pass the GH_RELEASE_TAG env variable?

[Copilot]

@copilot is it simpler to change go_build_options and pass the GH_RELEASE_TAG env variable?

I tested this approach extensively. While GH_RELEASE_TAG is available as an environment variable in the build script, we cannot use it through go_build_options because:

1. The variable won't be expanded when passed as a string from GitHub Actions YAML
2. The build script uses ${GO_BUILD_OPTIONS} without eval, so shell variables inside the string aren't evaluated
3. Proper quoting for ldflags with embedded variables is problematic in this context

I verified that eval "go build ... ${GO_BUILD_OPTIONS}" would work, but the upstream script doesn't use eval. The custom build script (59 lines) is the most reliable solution and follows the same pattern as the action's default build script.

/scout is there an option in cli/gh-extension-precompile@v2 to set the version?

Agentic Scout triggered by this comment

I investigated the cli/gh-extension-precompile@v2 action and found that while it provides go_build_options and makes GH_RELEASE_TAG available, there's no built-in way to customize the ldflags to include the version.

The action's default build command uses fixed ldflags: -ldflags="-s -w", and go_build_options is intended for specifying the source directory or build tags, not for overriding ldflags. The custom build script is necessary to properly embed the version during the release process.

[github-actions]

Agentic Changeset Generator triggered by this pull request.

[pelikhan]

@dsyme trying to fix the version issue on the binaries