Release artifacts missing from 0.73.1 release
erikgb opened this issue · comments
Is there an existing issue for this?
- I have searched the existing issues
What happened?
Description
We are using the stripped-down-crds.yaml from the release artifacts to install just the operator CRD. This file (and bundle.yaml) seems to be missing from the latest 0.73.1 release. I assume this was non-intentional.
Comparing https://github.com/prometheus-operator/prometheus-operator/releases/tag/v0.73.1 with https://github.com/prometheus-operator/prometheus-operator/releases/tag/v0.73.0
Steps to Reproduce
Expected Result
Actual Result
Prometheus Operator Version
0.73.1
Kubernetes Version
N/A
Kubernetes Cluster Type
kind
How did you deploy Prometheus-Operator?
prometheus-operator/kube-prometheus
Manifests
No response
prometheus-operator log output
N/A
Anything else?
No response
Right it was not intentional. Noticed that after creating release. But there is no change in CRD in 0.73.1 from 0.73.0, there was only bugfix to reduce logging.
I will attach the artifacts manually later today.
Thanks @slashpai! I was not expecting any changes to the CRDs. It just broke our CI. 😉
Just to make it clear: we strongly advocate to avoid using the stripped down CRDs since they lack description fields.
https://prometheus-operator.dev/docs/operator/troubleshooting/#customresourcedefinition--is-invalid-metadataannotations-too-long-issue explains how you can get rid of stripped down CRDs. Maybe there's room for improvement?
Just to make it clear: we strongly advocate to avoid using the stripped down CRDs since they lack description fields.
Thanks, but in this case, it is just to feed our ephemeral clusters used for feature branches with the CRDs - as simple as possible. In our "real" clusters, we install the operator using Helm (kube-prometheus-stack). For this setup, we actually just want the CRDs and not the operator etc.
Basically you need this? https://github.com/prometheus-operator/prometheus-operator/tree/main/example/prometheus-operator-crd
Would it make sense to provide a tarball with only the CRDs with each release? I don't like that we encourage people using the "stripped down" version :)
The release now includes the expected assets.
Thanks, appreciated!
Would it make sense to provide a tarball with only the CRDs with each release? I don't like that we encourage people using the "stripped down" version :)
In our case this would only complicate things. Why is there an "example" element in this path? 🤔 It confuses - at least me. Our preferred solution would be to add a kustomization.yaml
file to the CRD directory. That would make this as simple as it gets for us! If you are willing to accept a PR adding this, I could do it. WDYT?
definitely yes for supporting kustomize more broadly 😃