Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTel Collector Builder: strict versioning support #9896

Open
kristinapathak opened this issue Apr 5, 2024 · 0 comments
Open

OTel Collector Builder: strict versioning support #9896

kristinapathak opened this issue Apr 5, 2024 · 0 comments

Comments

@kristinapathak
Copy link
Contributor

kristinapathak commented Apr 5, 2024

Is your feature request related to a problem? Please describe.
When building a collector, it's possible to have a mismatch in the core library version and component versions. This can cause difficult to understand build failures, such as in #8692.

Describe the solution you'd like
When strict versioning is enabled, the builder could check the configured version for the core collector against any included component versions to ensure that they match, as well as ensure that the builder version and collector version match.

Describe alternatives you've considered
People modify their builder config until it works 🙁

Additional context
@mx-psi mentioned making this the default behavior instead of a flag. Is that something that others also want?

mx-psi added a commit that referenced this issue Apr 18, 2024
**Description:** <Describe what has changed.>
Adds strict version checking in the builder. This enables users to
ensure that the versions specified in the builder config are the
versions used in the go.mod when building the collector binary. This can
be disabled with --skip-strict-versioning.

**Link to tracking Issue:** #9896

**Testing:** Added unit tests

**Documentation:** Added to builder README

---------

Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
codeboten pushed a commit that referenced this issue Apr 19, 2024
#### Description
When building from a commit hash, I got this error:
```
Error: mismatch in go.mod and builder configuration versions: core collector version calculated by component dependencies "v0.98.1-0.20240416174005-d0f15e2463f8" does not match configured version "v0.98.0". Use --skip-strict-versioning to temporarily disable this check. This flag will be removed in a future minor version
```
It may be more useful to only compare the major and minor versions

#### Link to tracking issue
#9896
Found in
open-telemetry/opentelemetry-collector-contrib#32544

#### Testing
Manually tested new build

#### Documentation
updated readme
mx-psi added a commit that referenced this issue May 3, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
When running tests, waiting for `downloadModules()` to fail 3 times when
that's expected adds time to the test run. This updates tests to only
attempt downloading once. Note: if there's a network failure that could
cause `downloadModules()` to fail when it should normally succeed. Also
the wording here is `retries` when in actuality it's the number of
attempts. I didn't change this to keep the log wording the same, but I
can change the wording if that's preferable.

<!-- Issue number if applicable -->
#### Link to tracking issue
this will help for adding tests for
#9252
and
#9896

<!--Describe what testing was performed and which tests were added.-->
#### Testing
Tests ran

---------

Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
andrzej-stencel pushed a commit to andrzej-stencel/opentelemetry-collector that referenced this issue May 27, 2024
…10035)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
When running tests, waiting for `downloadModules()` to fail 3 times when
that's expected adds time to the test run. This updates tests to only
attempt downloading once. Note: if there's a network failure that could
cause `downloadModules()` to fail when it should normally succeed. Also
the wording here is `retries` when in actuality it's the number of
attempts. I didn't change this to keep the log wording the same, but I
can change the wording if that's preferable.

<!-- Issue number if applicable -->
#### Link to tracking issue
this will help for adding tests for
open-telemetry#9252
and
open-telemetry#9896

<!--Describe what testing was performed and which tests were added.-->
#### Testing
Tests ran

---------

Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants