Skip to content
dagweavedagweave docs

What it will refuse, and why

dagweave lint rules on the compiled pod spec a workflow would produce, not on which template fields it happens to use. That is deliberate: a strategic merge patch can add a field lint would otherwise never see written out in the template, and everything a workflow can say ends up in that one pod spec either way. Every field gets a verdict, so a version of Argo that adds a new one fails the build here rather than shipping as a silent gap.

Each finding is one of three things:

  • Refuse. The run stops before it starts. nodeSelector, affinity, serviceAccountName, resourceClaims, and anything reaching a template stored in the cluster are refused, because they would either do nothing on this machine or run against a Kubernetes concept a laptop has no honest answer for.
  • Warn, and run anyway. PVCs, hostPath, imagePullSecrets, and memory or CPU limits warn, because the hidden cluster’s own kubelet enforces them the way a real one would. You are told what is different, not stopped from running it.
  • Ignored, because it has no local meaning. tolerations, resources.requests, priorityClassName, and podDisruptionBudget all describe scheduling decisions that do not exist on a single node running for you alone.

Nothing is silently dropped. A field with no rule at all is refused by construction rather than let through unnoticed, which is what makes a Refuse here worth trusting when it appears.

What the gate cannot see

Section titled “What the gate cannot see”

The gate rules on a compiled Kubernetes pod spec. It has no way to see a step whose command shells out to kubectl or helm, because that command is just a string as far as the pod spec is concerned. Five items in dagweave’s own catalog do exactly that: helm-upgrade, kubectl-apply, kubectl-delete, scale-deployment, and wait-for-rollout. Lint passes all five. Running them does not go as well.

They fail on identity rather than on anything lint could have caught. The hidden cluster’s default service account can create, get, and patch pods and workflows, and nothing else: no delete verb, nothing in the apps group. So helm upgrade, kubectl scale, kubectl rollout status, and kubectl delete are all refused by Kubernetes’ own RBAC and fail loudly. kubectl apply is the one to watch instead of dismiss: it reads first and creates on a 404, so applying a manifest really does create an object, in the cluster you thought this binary was hiding you from. Rather than let that succeed quietly against the wrong cluster, catalog items that need real cluster-admin access declare it themselves, and Dagweave Local reads that declaration and refuses them before the run starts.

If you are authoring your own catalog-style step that shells out to kubectl or helm, assume Dagweave Local cannot see that from the pod spec alone, and that its default service account cannot do much beyond create, get, and patch pods and workflows.