<p>After a lot of playing around, I came to a working solution that I briefly mentioned in a comment in the original question. The CI is now creating a namespace on the cluster, running the dry run <code>apply</code> and then deleting the namespace when finished. Not sure if this is the perfect solution but it's working as I hoped.</p>
<pre><code>helm template . \
  --values common/values-common.yaml \
  --values variants/$VARIANT/values-$VARIANT.yaml \
  --name-template=github-actions-test \
  --set image.tag=github-actions-test \
  --namespace $NAMESPACE \
  --debug &gt; dry-run.yaml

kubectl create namespace $NAMESPACE --dry-run=client -o yaml | kubectl apply -f -
echo &quot;errors=$(kubectl create -f dry-run.yaml -n $NAMESPACE --dry-run=server -o yaml 2&gt;&amp;1 &gt; /dev/null)&quot; &gt;&gt; $GITHUB_OUTPUT
kubectl delete namespace $NAMESPACE
</code></pre>

CC BY-SA 4.0
2022-11-09T20:23:50.530Z
2022-11-09T20:23:50.530Z
PaReeOhNos
<p>We're using ArgoCD to manage deployments, and I'm in the process of sorting out the config repository. I'm planning on having pull requests for any change to the config, and I want to validate the configuration to ensure it's not breaking anything. I've done some looking around, and it looks like the main options are <code>kubeval</code>, <code>kubeconform</code> or using <code>--dry-run</code> with <code>kubectl</code>.</p>
<p>Due to kubectl actually connecting to the cluster, and have the cluster perform the validation I prefer this approach as it should catch every possible error, however I'm running into a problem.</p>
<p>One of the resources uses <code>generateName</code> which is not compatible with <code>kubectl apply</code>, so if I try and validate using <code>kubectl apply -f manifest.yaml --dry-run=server</code> I get the error <code>cannot use generate name with apply</code>. To get around this, I tried to use <code>kubectl create -f manifest.yaml --dry-run=server</code> but instead I get a load of errors about resources already existing (understandable).</p>
<p>So how can I do this? I can't use apply, and I can't use create. Are there any other options? Does anyone know what Argo uses to validate, because if I push something invalid it presents an error before it is told to sync.</p>

CC BY-SA 4.0
2022-10-29T08:26:55.673Z
dealing with generateNames, we might use BeforeHookCreation ( https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/#generate-name ). Although this would not answer your question regarding dry-runs ... leaving ArgoCD context/tip testing kube code: use k3s. You may start a k3s instance inside your Kubernetes cluster (or on your laptop), then work with that disposable API, and delete that container once you're done testing.
SYN
CC BY-SA 4.0
2022-10-29T08:29:32.400Z
here's a sample, using Tekton, testing a Kubernetes controller, authenticating against some disposable k3s sidecar: https://gitlab.com/synacksynack/opsperator/docker-operator/-/blob/master/roles/tekton/templates/task-test-operator-kind.j2 . For sure it could be simplified testing kubernetes yamls, helm charts, ... Keep in mind k3s is a lightweight version of kubernetes / might need to customize your k3s installation, or just create fake Custom Resources Definitions, depending on which objects you expect to test
SYN
CC BY-SA 4.0
2022-10-29T08:37:07.673Z
Reading back your question, I'm having doubts ... regarding the create/apply/generateName thing, abstracting from your stack, probably something like: `kubectl create -f manifest.yaml --dry-run -o yaml | kubectl apply --dry-run=server -f-`
SYN
CC BY-SA 4.0
2022-11-01T15:37:55.420Z
So far I've got close by actually creating a namespace, then running the create command with a dry run flag, then remove the namespace after. I tested it locally and it seemed to work so I'm just plumbing it into the CI at the moment and will report back.
PaReeOhNos
<kubernetes>
Validating kubernetes manifest with --dry-run and generateName
PaReeOhNos
# Validating kubernetes manifest with --dry-run and generateName

(Asked by: username_0 on 2022-10-26)

We're using ArgoCD to manage deployments, and I'm in the process of sorting out the config repository. I'm planning on having pull requests for any change to the config, and I want to validate the configuration to ensure it's not breaking anything. I've done some looking around, and it looks like the main options are `kubeval`, `kubeconform` or using `--dry-run` with `kubectl`.

Due to kubectl actually connecting to the cluster, and have the cluster perform the validation I prefer this approach as it should catch every possible error, however I'm running into a problem.

One of the resources uses `generateName` which is not compatible with `kubectl apply`, so if I try and validate using `kubectl apply -f manifest.yaml --dry-run=server` I get the error `cannot use generate name with apply`. To get around this, I tried to use `kubectl create -f manifest.yaml --dry-run=server` but instead I get a load of errors about resources already existing (understandable).

So how can I do this? I can't use apply, and I can't use create. Are there any other options? Does anyone know what Argo uses to validate, because if I push something invalid it presents an error before it is told to sync.

**Tags:** kubernetes

> **Comments:**
> **username_1**: dealing with generateNames, we might use BeforeHookCreation ( https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/#generate-name ). Although this would not answer your question regarding dry-runs ... leaving ArgoCD context/tip testing kube code: use k3s. You may start a k3s instance inside your Kubernetes cluster (or on your laptop), then work with that disposable API, and delete that container once you're done testing.  
> **username_1**: here's a sample, using Tekton, testing a Kubernetes controller, authenticating against some disposable k3s sidecar: https://gitlab.com/synacksynack/opsperator/docker-operator/-/blob/master/roles/tekton/templates/task-test-operator-kind.j2 . For sure it could be simplified testing kubernetes yamls, helm charts, ... Keep in mind k3s is a lightweight version of kubernetes / might need to customize your k3s installation, or just create fake Custom Resources Definitions, depending on which objects you expect to test  
> **username_1**: Reading back your question, I'm having doubts ... regarding the create/apply/generateName thing, abstracting from your stack, probably something like: `kubectl create -f manifest.yaml --dry-run -o yaml | kubectl apply --dry-run=server -f-`  
> **username_0**: So far I've got close by actually creating a namespace, then running the create command with a dry run flag, then remove the namespace after. I tested it locally and it seemed to work so I'm just plumbing it into the CI at the moment and will report back.  

---

## 1 answers

### Answer by username_0 on 2022-11-09. Score: 1 | Accepted answer

After a lot of playing around, I came to a working solution that I briefly mentioned in a comment in the original question. The CI is now creating a namespace on the cluster, running the dry run apply and then deleting the namespace when finished. Not sure if this is the perfect solution but it's working as I hoped.
helm template . \
  --values common/values-common.yaml \
  --values variants/$VARIANT/values-$VARIANT.yaml \
  --name-template=github-actions-test \
  --set image.tag=github-actions-test \
  --namespace $NAMESPACE \
  --debug > dry-run.yaml

kubectl create namespace $NAMESPACE --dry-run=client -o yaml | kubectl apply -f -
echo "errors=$(kubectl create -f dry-run.yaml -n $NAMESPACE --dry-run=server -o yaml 2>&1 > /dev/null)" >> $GITHUB_OUTPUT
kubectl delete namespace $NAMESPACE


---

