Looks like oldstable has not been updated yet

Codecov Report

❌ Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.79%. Comparing base (b7214f9) to head (bc4155a).
⚠️ Report is 1 commits behind head on main.

❌ Your patch status has failed because the patch coverage (81.81%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

@@            Coverage Diff             @@
##             main   #14567      +/-   ##
==========================================
- Coverage   91.82%   91.79%   -0.03%     
==========================================
  Files         679      679              
  Lines       42857    42839      -18     
==========================================
- Hits        39352    39324      -28     
- Misses       2438     2444       +6     
- Partials     1067     1071       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Okay after retrying we seem to have the following issues:

1. Modernize lint failure:

Error: confmap/resolver_test.go:402:2: waitgroup: Goroutine creation can be simplified using WaitGroup.Go (modernize)
	go func() {
	^
Error: confmap/resolver_test.go:540:2: waitgroup: Goroutine creation can be simplified using WaitGroup.Go (modernize)
	go func() {
	^

2. FIPS-140 failure cc @ycombinator

gotest.tools/gotestsum: gotest.tools/[email protected]: Get "https://proxy.golang.org/gotest.tools/gotestsum/@v/v1.13.0.zip": crypto/ecdh: use of X25519 is not allowed in FIPS 140-only mode

3. Contrib test failures like:

'stability' expected type 'component.StabilityLevel', got unconvertible type 'map[string]interface {}'
'metrics[active_directory.ds.replication.object.rate]' decoding failed due to the following error(s):

The contrib tests failures will be fixed with open-telemetry/opentelemetry-collector-contrib#45903

Okay gotestsum can run now, but there are now failures like

failed running go mod tidy: exit status 1 (go: finding module for package go.opentelemetry.io/collector/cmd/builder
        	            	go: finding module for package go.opentelemetry.io/collector/cmd/builder
        	            	go: go.opentelemetry.io/collector/cmd/builder: module go.opentelemetry.io/collector/cmd/builder: Get "https://proxy.golang.org/go.opentelemetry.io/collector/cmd/builder/@v/list": crypto/ecdh: use of X25519 is not allowed in FIPS 140-only mode

@ycombinator would appreciate your help!

@mx-psi i think that's all the linter errors, i don't know what to do about the fips thing

From golang/go#74630 (comment):

I mildly regret shipping fips140=only mode. It should be understood as a debugging mode, a way to discover non-compliance while testing, not as a security measure. But even as a debugging mode it is currently a broken debugging mode, because it makes absolute assertions (X25519 is not ok) when actually compliance is context-aware (X25519 is ok as part of a hybrid and SHA-1 is ok for non-security purposes). I don't know how to propagate that context without a bubble.

Should we disable the check for now?

A comment on another thread Azure/azure-sdk-for-go#25848 (comment):

The root cause of this panic is in the standard library and apparently fixed for Go 1.26 at least (see golang/go#74630 (comment) and related patch). The gist is, for TLS 1.3 crypto/tls selects an allowed hybrid KEM part of which uses a disallowed curve (X25519). Future Go versions won't panic in this case because they'll recognize X25519 as allowed in the context of this hybrid KEM. I suppose one way to avoid this panic in the meantime is to restrict clients to TLS 1.2, however we won't do that for the SDK's default configuration; application developers can override that if necessary.

From golang/go#74630 (comment):

I mildly regret shipping fips140=only mode. It should be understood as a debugging mode, a way to discover non-compliance while testing, not as a security measure. But even as a debugging mode it is currently a broken debugging mode, because it makes absolute assertions (X25519 is not ok) when actually compliance is context-aware (X25519 is ok as part of a hybrid and SHA-1 is ok for non-security purposes). I don't know how to propagate that context without a bubble.

Should we disable the check for now?

+1 to this

Disabled it in a separate PR, see #14571