Open dprotaso opened 8 months ago
Could you expand on what you dislike about this? Simply that there's an additional dependency?
I totally understand the ask; I think this would be a reasonable thing to add for a potential trust-manager v1, so I've added it to the milestone
Could you expand on what you dislike about this? Simply that there's an additional dependency?
More or less.
Also for CI and testing it's nice to just kubectl apply -f ${some_release_yaml_link}
I think adding this could make sense. It will also simplify our setup. We try to avoid Helm as much as possible and prefer kustomize. A present we inflate the Helm chart into resources client-side before including it in a kustomization for further processing.
It could be implemented as a simple helm template
using the chart default values - where the result is committed to Git. It might complicate the release process a bit, but I imagine it's doable. A benefit of this approach is a "smoke test" of Helm chart changes. I am assuming Helm will remain the master of resources.
The CRDs can no longer be downloaded standalone vs prior releases. Maybe a standalone yaml could be a release artifact?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Not a fan that helm is required to generate yamls to be used with
kubectl apply