OCPBUGS-92037: Synchronize From Upstream Repositories #757
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -63,3 +63,6 @@ site | |
|
|
||
| # Test profiling artifacts | ||
| test-profiles/ | ||
|
|
||
| # Per-cluster kubeconfig files for e2e tests | ||
| .kubeconfig/ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -35,8 +35,8 @@ require ( | |
| golang.org/x/exp v0.0.0-20260410095643-746e56fc9e2f | ||
| golang.org/x/mod v0.37.0 | ||
| golang.org/x/sync v0.21.0 | ||
| golang.org/x/tools v0.46.0 | ||
| helm.sh/helm/v3 v3.21.1 | ||
| k8s.io/api v0.36.1 | ||
| k8s.io/apiextensions-apiserver v0.36.1 | ||
| k8s.io/apimachinery v0.36.1 | ||
|
|
@@ -47,7 +47,7 @@ require ( | |
| k8s.io/klog/v2 v2.140.0 | ||
| k8s.io/kubernetes v1.36.1 | ||
| k8s.io/utils v0.0.0-20260319190234-28399d86e0b5 | ||
| pkg.package-operator.run/boxcutter v0.14.0 | ||
| sigs.k8s.io/controller-runtime v0.24.1 | ||
| sigs.k8s.io/controller-tools v0.21.0 | ||
| sigs.k8s.io/crdify v0.6.1-0.20260602124154-bb9957dbf465 | ||
|
|
@@ -57,11 +57,11 @@ require ( | |
|
|
||
| require ( | ||
| k8s.io/component-helpers v0.36.1 // indirect | ||
| k8s.io/kube-openapi v0.0.0-20260520065146-aa012df4f4af // indirect | ||
| ) | ||
|
|
||
| require ( | ||
| cel.dev/expr v0.25.2 // indirect | ||
| dario.cat/mergo v1.0.2 // indirect | ||
| github.com/AdaLogics/go-fuzz-headers v0.0.0-20240806141605-e8a1dd7889d6 // indirect | ||
| github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c // indirect | ||
|
|
@@ -107,7 +107,7 @@ require ( | |
| github.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f // indirect | ||
| github.com/fatih/color v1.19.0 // indirect | ||
| github.com/felixge/httpsnoop v1.0.4 // indirect | ||
| github.com/fxamacker/cbor/v2 v2.9.2 // indirect | ||
| github.com/go-errors/errors v1.5.1 // indirect | ||
| github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 // indirect | ||
| github.com/go-git/go-billy/v5 v5.9.0 // indirect | ||
|
|
@@ -116,7 +116,7 @@ require ( | |
| github.com/go-jose/go-jose/v4 v4.1.4 // indirect | ||
| github.com/go-logr/stdr v1.2.2 // indirect | ||
| github.com/go-openapi/jsonpointer v0.23.1 // indirect | ||
| github.com/go-openapi/jsonreference v0.21.6 // indirect | ||
| github.com/go-openapi/swag v0.26.0 // indirect | ||
| github.com/go-openapi/swag/cmdutils v0.26.0 // indirect | ||
| github.com/go-openapi/swag/conv v0.26.0 // indirect | ||
|
|
@@ -160,10 +160,10 @@ require ( | |
| github.com/klauspost/pgzip v1.2.6 // indirect | ||
| github.com/lann/builder v0.0.0-20180802200727-47ae307949d0 // indirect | ||
| github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 // indirect | ||
| github.com/lib/pq v1.12.3 // indirect | ||
| github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect | ||
| github.com/mattn/go-colorable v0.1.14 // indirect | ||
| github.com/mattn/go-isatty v0.0.22 // indirect | ||
| github.com/mattn/go-runewidth v0.0.23 // indirect | ||
| github.com/mattn/go-sqlite3 v1.14.45 // indirect | ||
| github.com/miekg/pkcs11 v1.1.2 // indirect | ||
|
|
@@ -215,22 +215,22 @@ require ( | |
| go.opencensus.io v0.24.0 // indirect | ||
| go.opentelemetry.io/auto/sdk v1.2.1 // indirect | ||
| go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.68.0 // indirect | ||
| go.opentelemetry.io/otel v1.44.0 // indirect | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.43.0 // indirect | ||
| go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.43.0 // indirect | ||
| go.opentelemetry.io/otel/metric v1.44.0 // indirect | ||
| go.opentelemetry.io/otel/sdk v1.43.0 // indirect | ||
| go.opentelemetry.io/otel/trace v1.44.0 // indirect | ||
| go.opentelemetry.io/proto/otlp v1.10.0 // indirect | ||
| go.podman.io/common v0.68.0 // indirect | ||
| go.podman.io/storage v1.63.0 // indirect | ||
| go.yaml.in/yaml/v2 v2.4.4 // indirect | ||
| go.yaml.in/yaml/v3 v3.0.4 // indirect | ||
| golang.org/x/crypto v0.53.0 // indirect | ||
| golang.org/x/net v0.56.0 // indirect | ||
| golang.org/x/oauth2 v0.36.0 // indirect | ||
| golang.org/x/sys v0.46.0 // indirect | ||
| golang.org/x/term v0.44.0 // indirect | ||
|
Comment on lines
+218
to
+233
There was a problem hiding this comment. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
rg -n 'go\.opentelemetry\.io/otel(/| )|go\.opentelemetry\.io/otel/exporters/otlp|go\.opentelemetry\.io/otel/sdk|go\.opentelemetry\.io/otel/trace|go\.opentelemetry\.io/otel/metric' go.mod openshift/tests-extension/go.modRepository: openshift/operator-framework-operator-controller Length of output: 1182 🌐 Web query:
💡 Result: In the OpenTelemetry Go ecosystem, modules are not guaranteed to be compatible simply by matching major versions; true compatibility is typically only assured for releases originating from the same commit [1]. While OpenTelemetry generally follows semantic versioning and aims for backward compatibility within a major version, relying on different minor versions across SDK components (e.g., mixing v1.43.0 and v1.44.0) can lead to unexpected runtime issues or dependency conflicts [1][2][3]. Key considerations for managing OpenTelemetry Go versions include: Dependency Consistency: OpenTelemetry maintainers typically release stable modules in unison, meaning they are tested and validated together [4]. Mixing minor versions (such as using v1.43.0 for the SDK and v1.44.0 for an OTLP exporter) is discouraged because it can result in conflicting internal dependencies, particularly when packages share underlying code or schema requirements [2][4]. Versioning Policy: OpenTelemetry Go follows standard Go module versioning [5][6]. Although the API guarantees backward compatibility for its stable components [7][3], mixing minor versions in your go.mod file may cause your build to pull in conflicting versions of transitive dependencies, which can lead to runtime errors, such as merging conflicts in Resource objects [2]. Best Practices: - Keep all OpenTelemetry modules at the same minor version (e.g., all at v1.44.0) to ensure the components are functionally aligned [3][4]. - If you encounter build or runtime issues after a partial upgrade, the recommended solution is to align all OpenTelemetry dependencies to the same version [3]. - When upgrading, it is generally safe and recommended to upgrade the entire suite of OpenTelemetry packages to the latest minor version to receive security patches and optimizations [3]. If you find that mixing versions is necessary for a specific reason, you should rigorously test the application, as the project does not explicitly guarantee compatibility across different minor versions of the SDK and exporters [1][3]. Citations:
Align the OpenTelemetry module versions
🤖 Prompt for AI Agents |
||
| golang.org/x/text v0.38.0 // indirect | ||
| golang.org/x/time v0.15.0 // indirect | ||
| gomodules.xyz/jsonpatch/v2 v2.5.0 // indirect | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: openshift/operator-framework-operator-controller
Length of output: 186
🏁 Script executed:
Repository: openshift/operator-framework-operator-controller
Length of output: 10696
🏁 Script executed:
Repository: openshift/operator-framework-operator-controller
Length of output: 249
🌐 Web query:
GNU make target-specific variable assignment ?= inherited prerequisite precedence💡 Result:
In GNU make, target-specific variable assignments—including the conditional assignment operator?=—function within the context of a specific target and are inherited by its prerequisites [1][2]. Key behaviors regarding target-specific variables and their inheritance include: 1. Inheritance Mechanism: When you define a target-specific variable, its value remains in effect for the recipe of that target and for the recipes of all its prerequisites (and their descendants), unless a prerequisite explicitly overrides it with its own target-specific variable value [2][3]. 2. Conditional Assignment (?=): The?= operator sets a variable only if it is not already defined [4]. When used as a target-specific assignment, it checks if the variable is defined within the context of the target. Because target-specific variables are effectively distinct from global variables, a target-specific?= assignment will use the global value if no target-specific value has been set yet, or it will do nothing if a target-specific value already exists for that target [1]. 3. Prerequisite Precedence and Scope: Target-specific variables are only available within the context of a target’s recipe and in other target-specific assignments [1][2]. They are generally not available during the initial parsing phase or in the prerequisite list of a rule [5][6]. If a file is a prerequisite for multiple targets, it inherits the target-specific variable values from the first target that triggers its build [1]. Prerequisites do not inherit target-specific variables from each other, only from the parent target that is currently being built [6]. 4. Precedence: Target-specific variables have the same priority as other makefile variables but are overridden by variables defined on the command line or via the override directive [1][2]. If a prerequisite has its own target-specific variable defined for the same variable name, that definition takes precedence over the inherited value [2][6].
Citations:
Preserve the experimental timeout override. The
?=one2e-run-%won’t override the inheritedE2E_TIMEOUT=25mfromtest-experimental-e2e, so the experimental suite can still run with the 25m value. Move the fallback into the recipe or setE2E_TIMEOUTunconditionally one2e-run-%.🧰 Tools
🪛 checkmake (0.3.2)
[warning] 339-339: Target "test-experimental-e2e" defined multiple times (lines 334 and 339).
(uniquetargets)
🤖 Prompt for AI Agents