k.kubectl.WaitForDeletions does bail on new CRDs #4641
Description
Unless switched off ...
func (c *CLI) WaitForDeletions(ctx context.Context, out io.Writer, manifests ManifestList) error {
if !c.waitForDeletions.Enabled {
return nil
}
[...]... WaitForDeletions does perform kubectl get on the manifests.Reader()ed output.
Given the case, that manifests.Reader()ed output contains CRDs unbeknownst to the cluster, the call to kubectl get just bails without further due:
if err != nil {
return err
}However, in the context of developing the k8s manifest of an application which include CRDs, one does not want to hit a cryptic error message which forces one to debug skaffold code to see what's going on.
Therfore, either provide an actionable error message which instructs to disable waitForDeletions on the cli (eg. by parsing the kubectl error message), or reconcile CRDs used in those manifests intelligently prior to proceeding with WaitForDeletions, or filtering out non-available CRDs from the manifests.Reader()ed output.
Considerations: In the context and intent of WaitForDeletions, maybe filtering out those CRDs from the input manifest is the most consistent and safe solution, since at the and of WaitForDeletions, all resources shall be deleted anyway.
Here is the actual log snippet:
exiting dev mode because first deploy failed: running [kubectl --context k3d-k3s-default get -f - --ignore-not-found -ojson]
- stdout: ""
- stderr: "error: unable to recognize \"STDIN\": no matches for kind \"ClusterIssuer\" in version \"cert-manager.io/v1alpha2\"\n"
- cause: exit status 1Note, that it is deceiving that --ignore-not-found in
buf, err := c.RunOutInput(ctx, manifests.Reader(), "get", c.args(nil, "-f", "-", "--ignore-not-found", "-ojson")...)apparently does not apply to resource definitions, only to resources. Which, though deceiving, is kind of consistent - depending on the viewpoint.
/cc @dgageot - since you last modified those lines.