Skip to content

Conversation

@andrzej-janczak
Copy link
Contributor

@andrzej-janczak andrzej-janczak commented May 14, 2025

fix: version passing to GoReleaser configuration

Fix version command by properly configuring GoReleaser and version injection:

  • Update GoReleaser to use version constraint (~> v1) instead of 'latest'
  • Fix version information injection through ldflags
  • Add proper environment variable handling for Go version

This ensures the version command shows correct build information
and follows GoReleaser's best practices for version constraints.

@codacy-production
Copy link

codacy-production bot commented May 14, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
+0.00%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (c584641) 4240 1568 36.98%
Head commit (f2b48a5) 4240 (+0) 1568 (+0) 36.98% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#115) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

- Change Go version retrieval method in .goreleaser.yaml to use GOVERSION from environment variables.
- Add a step in GitHub Actions workflow to extract and set the Go version for use in the release process.
- Change GoReleaser version from 'latest' to '~> v1' in GitHub Actions workflow to ensure compatibility with specific version range.
distribution: goreleaser
# 'latest', 'nightly', or a semver
version: "latest"
version: "~> v1"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

his change to version: "~> v1" means:
You'll always get the latest v1.x.x release
You're protected from breaking changes that might come in v2.0.0
You'll automatically get bug fixes and minor improvements within the v1 series
It's more flexible than pinning to a specific version while still maintaining stability
This is what the warning was suggesting as a best practice, and it's a better approach than either using latest (too loose) or a specific version like v1.21.1 (too strict).

@andrzej-janczak andrzej-janczak enabled auto-merge (squash) May 14, 2025 11:08
@andrzej-janczak andrzej-janczak changed the title Fix: release with version commnad Fix: version passing to GoReleaser configuration May 14, 2025
@andrzej-janczak andrzej-janczak merged commit 4b73f12 into main May 14, 2025
8 checks passed
@andrzej-janczak andrzej-janczak mentioned this pull request May 14, 2025
andrzej-janczak added a commit that referenced this pull request May 14, 2025
Revert some changes made with #115
@alerizzo alerizzo deleted the fix/release branch June 3, 2025 09:45
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.

3 participants