You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Converted Stanza to a single module. Managing multiple modules complicates the release process. Now that Stanza's core has been implemented into Open Telemetry, we can safely manage Stanza as a single module.
This meant the existing versioning system would need to be replaced. I opted for variable injection at build time by leveraging GIT_TAG and GIT_COMMIT environment variables.
Makefile will set GIT_COMMIT.
➜ stanza git:(single-module) ✗ make build-darwin-amd64
➜ stanza git:(single-module) ✗ artifacts/stanza_darwin_amd64 version
git-commit: 7b83971df04c378599515fef09ef895bbdf5170d
If GIT_TAG is set, it will take precedence over GIT_COMMIT
➜ stanza git:(single-module) ✗ export GIT_TAG=v1.2
➜ stanza git:(single-module) ✗ make build-darwin-amd64
➜ stanza git:(single-module) ✗ artifacts/stanza_darwin_amd64 version
v1.2
TODO: Determine the new Stanza version and update the changelog. I believe this is technically not a breaking change, individual packages can still be imported and used by external applications.
Please check that the PR fulfills these requirements
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)
Add a changelog entry (for non-trivial bug fixes / features)
This meant the existing versioning system would need to be replaced. I opted for variable injection at build time by leveraging GIT_TAG and GIT_COMMIT environment variables.
Can you explain this further? Certainly we would need to increment the version of stanza, but I'm not clear on why the whole versioning system needs to be reworked. Are you sure?
This meant the existing versioning system would need to be replaced. I opted for variable injection at build time by leveraging GIT_TAG and GIT_COMMIT environment variables.
Can you explain this further? Certainly we would need to increment the version of stanza, but I'm not clear on why the whole versioning system needs to be reworked. Are you sure?
We would get the stanza module version from cmd/stanza/go.mod
github.com/observiq/stanza v0.13.18
We used a package to read the module version when calling stanza version. Now, if you add stanza to go.mod, it will get removed during the build.
➜ stanza git:(single-module) ✗ make build-darwin-amd64
(cd ./cmd/stanza && \
CGO_ENABLED=0 \
go build \
-ldflags "-X github.com/observiq/stanza/version.GitTag= -X github.com/observiq/stanza/version.GitCommit=573b7aad2b8db684657bc8afecd5d68b199dd1e7" \
-o ../../artifacts/stanza_darwin_amd64 .)
go: github.com/observiq/[email protected]: missing go.sum entry; to add it:
go mod download github.com/observiq/stanza
make[1]: *** [build] Error 1
make: *** [build-darwin-amd64] Error 2
➜ stanza git:(single-module) ✗ go mod download github.com/observiq/stanza
go mod download: skipping argument github.com/observiq/stanza that resolves to the main module
We could set the version in the version package, instead of relying on the module package (and avoid the build time variable injection). I don't have a strong opinion on either option.
I think we should look for a way to use v0.0.0 format, since that's very standard in Go. Certainly the module needs to follow this format, so it would make sense that the agent itself should have the same version.
Ideally, the release process we have (creating a github release) would set the version based on the git tag (v0.0.0). This should be doable in the CI workflow, and would mean that it's the only place where the version is actually set. Builds created locally would not be versioned, or could be versioned as you have now.
I think we should look for a way to use v0.0.0 format, since that's very standard in Go. Certainly the module needs to follow this format, so it would make sense that the agent itself should have the same version.
Ideally, the release process we have (creating a github release) would set the version based on the git tag (v0.0.0). This should be doable in the CI workflow, and would mean that it's the only place where the version is actually set. Builds created locally would not be versioned, or could be versioned as you have now.
Thoughts on this approach?
I believe this is exactly what I am doing. When running in CircleCI, we will use the git tag. So the same release process exists:
Create draft release
Let Circle build the release and tag with v0.0.0
Publish the release
stanza version will return the git tag v0.0.0.
I added GIT_COMMIT versioning for local builds only. If you run make build without GIT_TAG set in your environment, The Makefile will inject GIT_COMMIT for the version. This could easily be removed.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Converted Stanza to a single module. Managing multiple modules complicates the release process. Now that Stanza's core has been implemented into Open Telemetry, we can safely manage Stanza as a single module.
This meant the existing versioning system would need to be replaced. I opted for variable injection at build time by leveraging GIT_TAG and GIT_COMMIT environment variables.
Makefile will set GIT_COMMIT.
If GIT_TAG is set, it will take precedence over GIT_COMMIT
TODO: Determine the new Stanza version and update the changelog. I believe this is technically not a breaking change, individual packages can still be imported and used by external applications.
Please check that the PR fulfills these requirements