Add support for kubectl installation

[dprotaso]

Not a fan that helm is required to generate yamls to be used with kubectl apply

[SgtCoDFish]

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

[dprotaso]

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}

[erikgb]

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.

[rajatvig]

The CRDs can no longer be downloaded standalone vs prior releases. Maybe a standalone yaml could be a release artifact?

[cert-manager-bot]

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

[cert-manager-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale

[dprotaso]

Any plans for a non-helm releases?

[dprotaso]

/lifecycle frozen