opentelemetry-collector
opentelemetry-collector copied to clipboard
[cmd/builder] test error when creating new release
The following error occurs in the builder unit tests during the creation of the new release: https://github.com/open-telemetry/opentelemetry-collector/actions/runs/10571488001/job/29287662515?pr=10973
--- FAIL: TestGetModules/Exporter_Not_in_Gomod (0.34s)
main_test.go:651:
Error Trace: /home/runner/work/opentelemetry-collector/opentelemetry-collector/cmd/builder/internal/builder/main_test.go:651
Error: Received unexpected error:
failed to update go.mod: go subcommand failed with args '[mod tidy -compat=1.22]': exit status 1, error message: go: downloading go.opentelemetry.io/collector/confmap/provider/envprovider v0.108.0
go: downloading go.opentelemetry.io/collector/confmap/provider/fileprovider v0.108.0
go: downloading go.opentelemetry.io/collector/confmap/provider/httpprovider v0.108.0
go: downloading go.opentelemetry.io/collector/confmap/provider/httpsprovider v0.108.0
go: downloading go.opentelemetry.io/collector/confmap/provider/yamlprovider v0.108.0
go: downloading go.opentelemetry.io/collector/otelcol v0.108.0
go: go.opentelemetry.io/collector/confmap/provider/[email protected]: reading go.opentelemetry.io/collector/confmap/provider/envprovider/go.mod at revision confmap/provider/envprovider/v0.108.0: unknown revision confmap/provider/envprovider/v0.108.0
May be related to changes in https://github.com/open-telemetry/opentelemetry-collector/pull/10098. @kristinapathak @mx-psi any help would be appreciated
Revert the change to unblock the release https://github.com/open-telemetry/opentelemetry-collector/pull/10978, will leave the issue open to ensure the change is re-applied in a future release
Removing the blocker label as the change has been reverted for now
I had a lot of problems with these unit tests - largely from breaking api changes in builder dependencies or new dependencies in the builder. This error was the result and honestly wasn't helpful in figuring out what the problem was. Given that these changes can happen at any time but don't cause the tests to fail until the default version is updated, I'm not sure what else to do here. With the current state of things, the tests are too brittle. The two options I see are:
- Give up on the
--skip-new-go-moduleflag - Reopen my PR with fewer tests and less coverage
CC @mx-psi @jaronoff97 @jmacd
I'm an OTEL user (rather than a developer), and I'm encountering the same error as above:
go: go.opentelemetry.io/collector/confmap/provider/[email protected]: reading go.opentelemetry.io/collector/confmap/provider/envprovider/go.mod at revision confmap/provider/envprovider/v0.135.0: unknown revision confmap/provider/envprovider/v0.135.0
Note that similar happens with v0.134.0, v0.133.0.
Interestingly, I can trigger this error by changing my builder config.
This works:
dist:
description: 'OTel Collector I want to build'
name: 'otelcol-sample'
output_path: './otelcol-sample'
providers:
- gomod: "go.opentelemetry.io/collector/confmap/provider/envprovider v0.135.0"
- gomod: "go.opentelemetry.io/collector/confmap/provider/fileprovider v0.135.0"
receivers:
- gomod: "go.opentelemetry.io/collector/receiver/otlpreceiver v0.135.0"
processors:
- gomod: "go.opentelemetry.io/collector/processor/batchprocessor v0.135.0"
- gomod: "go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.135.0"
exporters:
- gomod: "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/googlecloudexporter v0.135.0"
- gomod: "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/googlemanagedprometheusexporter v0.135.0"
- gomod: "go.opentelemetry.io/collector/exporter/debugexporter v0.135.0"
extensions: [] # none
This fails:
dist:
description: 'OTel Collector I want to build'
name: 'otelcol-sample'
output_path: './otelcol-sample'
providers:
- gomod: "go.opentelemetry.io/collector/confmap/provider/envprovider v0.135.0"
- gomod: "go.opentelemetry.io/collector/confmap/provider/fileprovider v0.135.0"
receivers:
- gomod: "go.opentelemetry.io/collector/receiver/otlpreceiver v0.135.0"
processors:
- gomod: "go.opentelemetry.io/collector/processor/batchprocessor v0.135.0"
- gomod: "go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.135.0"
exporters:
- gomod: "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/googlecloudexporter v0.135.0"
- gomod: "go.opentelemetry.io/collector/exporter/debugexporter v0.135.0"
extensions: [] # none
The only difference... removing this exporter induces the breakage:
- gomod: "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/googlemanagedprometheusexporter v0.135.0"
Digging into this, I found that releases are versioned differently between opentelemetry-collector and opentelemetry-collector-contrib. -contrib suggests that its releases include non-contrib, and non-contrib's GitHub releases show both non-contrib and contrib semvers.
I speculate that this multi-semver handwaving is breaking somewhere deep within Golang dependency resolution, since -contrib specifies its dependency on envprovider using the non-contrib versions:
https://github.com/search?q=repo%3Aopen-telemetry%2Fopentelemetry-collector-contrib%20go.opentelemetry.io%2Fcollector%2Fconfmap%2Fprovider%2Fenvprovider&type=code
Upon yet more digging, this working file suggests something along the lines of above.
dist:
description: 'OTel Collector I want to build'
name: 'otelcol-sample'
output_path: './otelcol-sample'
providers:
- gomod: "go.opentelemetry.io/collector/confmap/provider/envprovider v1.41.0"
- gomod: "go.opentelemetry.io/collector/confmap/provider/fileprovider v1.41.0"
receivers:
- gomod: "go.opentelemetry.io/collector/receiver/otlpreceiver v0.135.0"
processors:
- gomod: "go.opentelemetry.io/collector/processor/batchprocessor v0.135.0"
exporters:
- gomod: "github.com/open-telemetry/opentelemetry-collector-contrib/exporter/googlecloudexporter v0.135.0"
- gomod: "go.opentelemetry.io/collector/exporter/debugexporter v0.135.0"
extensions: [] # none
Using non-contrib semver for the providers allowed me to remove the googlemanagedprometheusexporter. I speculate that something in its dependencies was masking the underlying semver confusion.
@codeboten... I suspect the above doesn't belong on this GitHub issue. Is there a better place to raise this?