OLM v0.29.0 release contains incorrect olm.yaml attachment

[whatsacomputertho]

Bug Report

What did you do? I downloaded the olm.yaml attachment on the recent v0.29.0 release https://github.com/operator-framework/operator-lifecycle-manager/releases/tag/v0.29.0

And found that the CSV refers to OLM v0.19.0. Similarly, the image digest in the attached CSV does not correspond to the v0.29.0 tag.

Attached digest ref

quay.io/operator-framework/olm@sha256:cfdda06700fae2962ac89e677c1968517f8c5fae838ca31774b909f545d7be37

v0.29.0 digest

% skopeo inspect docker://quay.io/operator-framework/olm:v0.29.0 | jq .Digest

"sha256:eae9622a7e28657e896cd8ca258773f32fc3d5eea00c6d5712a79caa4e7c6ee4"

Attached OLM CSV

```yaml apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: name: packageserver namespace: olm labels: olm.version: v0.19.0 spec: displayName: Package Server description: Represents an Operator package that is available from a given CatalogSource which will resolve to a ClusterServiceVersion. minKubeVersion: 1.11.0 keywords: ['packagemanifests', 'olm', 'packages'] maintainers: - name: Red Hat email: openshift-operators@redhat.com provider: name: Red Hat links: - name: Package Server url: https://github.com/operator-framework/operator-lifecycle-manager/tree/master/pkg/package-server installModes: - type: OwnNamespace supported: true - type: SingleNamespace supported: true - type: MultiNamespace supported: true - type: AllNamespaces supported: true install: strategy: deployment spec: clusterPermissions: - serviceAccountName: olm-operator-serviceaccount rules: - apiGroups: - authorization.k8s.io resources: - subjectaccessreviews verbs: - create - get - apiGroups: - "" resources: - configmaps verbs: - get - list - watch - apiGroups: - "operators.coreos.com" resources: - catalogsources verbs: - get - list - watch - apiGroups: - "packages.operators.coreos.com" resources: - packagemanifests verbs: - get - list deployments: - name: packageserver spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 replicas: 2 selector: matchLabels: app: packageserver template: metadata: labels: app: packageserver spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault serviceAccountName: olm-operator-serviceaccount nodeSelector: kubernetes.io/os: linux containers: - name: packageserver securityContext: allowPrivilegeEscalation: false capabilities: drop: [ "ALL" ] command: - /bin/package-server - -v=4 - --secure-port - "5443" - --global-namespace - olm image: quay.io/operator-framework/olm@sha256:cfdda06700fae2962ac89e677c1968517f8c5fae838ca31774b909f545d7be37 imagePullPolicy: Always ports: - containerPort: 5443 protocol: TCP livenessProbe: httpGet: scheme: HTTPS path: /healthz port: 5443 readinessProbe: httpGet: scheme: HTTPS path: /healthz port: 5443 terminationMessagePolicy: FallbackToLogsOnError resources: requests: cpu: 10m memory: 50Mi volumeMounts: - name: tmpfs mountPath: /tmp volumes: - name: tmpfs emptyDir: {} maturity: alpha version: v0.19.0 apiservicedefinitions: owned: - group: packages.operators.coreos.com version: v1 kind: PackageManifest name: packagemanifests displayName: PackageManifest description: A PackageManifest is a resource generated from existing CatalogSources and their ConfigMaps deploymentName: packageserver containerPort: 5443 ```

What did you expect to see?

I expect the v0.29.0 CSV to be attached to the v0.29.0 release.

What did you see instead? Under which circumstances?

The v0.19.0 CSV is attached to the v0.29.0 release.

Environment

• operator-lifecycle-manager version: v0.29.0

• Kubernetes version information: N/a

• Kubernetes cluster kind: N/a

Possible Solution

Additional context Add any other context about the problem here.

[jon-nfc]

can confirm what OP has reported.

My question is,

is it only olm.yaml affected or are crds.yaml affected too?

[shantanu-dahiya]

I believe it's only olm.yaml because replacing the sha with the correct one in olm.yaml gets OLM working without any other changes.

[jon-nfc]

I believe it's only olm.yaml because replacing the sha with the correct one in olm.yaml gets OLM working without any other changes.

That's not confirmation of crd.yml not being affect, an inspection of the build system will be required.

[shantanu-dahiya]

Feel free to inspect it then

[jon-nfc]

Feel free to inspect it then

Real helpful!!! in your comment you used "believe" which clearly denotes you are uncertain. Me inspect it?????? that's why it was a question which clearly alludes to not have the required requisites to do so myself.

Confirmation will be required to be done instead of just "believing" it's OK. The beauty about code is it's ALWAYS certain.

[m1kola]

I'm closing this as a duplicate of #3419