[chore] Update additional modules to psuedo versions #11503
Merged
Conversation
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
|
Why is this important and where? |
|
Running |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #11503 +/- ##
=======================================
Coverage 91.47% 91.47%
=======================================
Files 433 433
Lines 23616 23616
=======================================
Hits 21603 21603
Misses 1645 1645
Partials 368 368 ☔ View full report in Codecov by Sentry. |
After we do the release this is not a problem correct? So then why not doing the release? |
|
The first step in the releasing document says to run this to check for errors. You're right that this shouldn't be a problem after the release, but this is my first release, so I'm looking to play it safe and double-check before releasing core. |
|
I understand, but I am confused about changes to |
|
|
This shouldn't impact the version of the module that is obtained, but is technically a better psuedo-version number
sfc-gh-bdrutu
approved these changes
Oct 21, 2024
bogdandrutu
approved these changes
Oct 21, 2024
mx-psi
pushed a commit
that referenced
this pull request
Oct 22, 2024
…pendencies (#11509) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Say we have three modules, A, B, and C, with dependencies C->B->A. If we are on commit 1, and make a new commit, 2, where we change the dependencies such that the go.mod files read C@2->B@1->A@1, we will still get a failure, because at commit 1 we had not yet made the changes necessary to properly resolve these modules. Specifically, at commit 2 we have B@1->A@#, where A@# is not externally-resolvable. We therefore need to make a new commit 3, where we can have C@2->B@2->A@2, and at commit 2 all modules are externally-resolvable. This PR is a necessary update to #11503. When running `make update-otel` in contrib, I am seeing the following errors: ``` go: downloading go.opentelemetry.io/collector/connector/connectortest v0.0.0-20241021181817-007f06b7c4a8 go: go.opentelemetry.io/collector/pipeline/pipelineprofiles@v0.111.0: reading go.opentelemetry.io/collector/pipeline/pipelineprofiles/go.mod at revision pipeline/pipelineprofiles/v0.111.0: unknown revision pipeline/pipelineprofiles/v0.111.0 ``` connectortest has an indirect dependency on pipelineprofiles, and at commit `007f06b7c4a8` pipelineprofiles is versioned at v0.111.0. The latest commit, `403c782d50c6`, will version it at `007f06b7c4a8`. Since pipelineprofiles has no dependencies, this will not result in any issues.
djaglowski
pushed a commit
to djaglowski/opentelemetry-collector
that referenced
this pull request
Nov 21, 2024
…11503) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Convert additional modules to use pseudo-version numbers. In cases where the module already has a released version, upgrade to pseudo versions to prevent ambiguous import errors (e.g. processor and processortest).
djaglowski
pushed a commit
to djaglowski/opentelemetry-collector
that referenced
this pull request
Nov 21, 2024
…pendencies (open-telemetry#11509) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Say we have three modules, A, B, and C, with dependencies C->B->A. If we are on commit 1, and make a new commit, 2, where we change the dependencies such that the go.mod files read C@2->B@1->A@1, we will still get a failure, because at commit 1 we had not yet made the changes necessary to properly resolve these modules. Specifically, at commit 2 we have B@1->A@#, where A@# is not externally-resolvable. We therefore need to make a new commit 3, where we can have C@2->B@2->A@2, and at commit 2 all modules are externally-resolvable. This PR is a necessary update to open-telemetry#11503. When running `make update-otel` in contrib, I am seeing the following errors: ``` go: downloading go.opentelemetry.io/collector/connector/connectortest v0.0.0-20241021181817-007f06b7c4a8 go: go.opentelemetry.io/collector/pipeline/pipelineprofiles@v0.111.0: reading go.opentelemetry.io/collector/pipeline/pipelineprofiles/go.mod at revision pipeline/pipelineprofiles/v0.111.0: unknown revision pipeline/pipelineprofiles/v0.111.0 ``` connectortest has an indirect dependency on pipelineprofiles, and at commit `007f06b7c4a8` pipelineprofiles is versioned at v0.111.0. The latest commit, `403c782d50c6`, will version it at `007f06b7c4a8`. Since pipelineprofiles has no dependencies, this will not result in any issues.
HongChenTW
pushed a commit
to HongChenTW/opentelemetry-collector
that referenced
this pull request
Dec 19, 2024
…11503) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Convert additional modules to use pseudo-version numbers. In cases where the module already has a released version, upgrade to pseudo versions to prevent ambiguous import errors (e.g. processor and processortest).
HongChenTW
pushed a commit
to HongChenTW/opentelemetry-collector
that referenced
this pull request
Dec 19, 2024
…pendencies (open-telemetry#11509) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Say we have three modules, A, B, and C, with dependencies C->B->A. If we are on commit 1, and make a new commit, 2, where we change the dependencies such that the go.mod files read C@2->B@1->A@1, we will still get a failure, because at commit 1 we had not yet made the changes necessary to properly resolve these modules. Specifically, at commit 2 we have B@1->A@#, where A@# is not externally-resolvable. We therefore need to make a new commit 3, where we can have C@2->B@2->A@2, and at commit 2 all modules are externally-resolvable. This PR is a necessary update to open-telemetry#11503. When running `make update-otel` in contrib, I am seeing the following errors: ``` go: downloading go.opentelemetry.io/collector/connector/connectortest v0.0.0-20241021181817-007f06b7c4a8 go: go.opentelemetry.io/collector/pipeline/pipelineprofiles@v0.111.0: reading go.opentelemetry.io/collector/pipeline/pipelineprofiles/go.mod at revision pipeline/pipelineprofiles/v0.111.0: unknown revision pipeline/pipelineprofiles/v0.111.0 ``` connectortest has an indirect dependency on pipelineprofiles, and at commit `007f06b7c4a8` pipelineprofiles is versioned at v0.111.0. The latest commit, `403c782d50c6`, will version it at `007f06b7c4a8`. Since pipelineprofiles has no dependencies, this will not result in any issues.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Convert additional modules to use pseudo-version numbers. In cases where the module already has a released version, upgrade to pseudo versions to prevent ambiguous import errors (e.g. processor and processortest).