Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-11-09T20:23:50.530Z
Answers: 2022-11-09T20:23:50.530Z
Answers: PaReeOhNos
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2022-10-29T08:26:55.673Z
Comments: 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.
Comments: SYN
Comments: CC BY-SA 4.0
Comments: 2022-10-29T08:29:32.400Z
Comments: 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
Comments: SYN
Comments: CC BY-SA 4.0
Comments: 2022-10-29T08:37:07.673Z
Comments: 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-`
Comments: SYN
Comments: CC BY-SA 4.0
Comments: 2022-11-01T15:37:55.420Z
Comments: 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.
Comments: PaReeOhNos
Tags: <kubernetes>
Title: Validating kubernetes manifest with --dry-run and generateName
UserDisplayName: PaReeOhNos
ThreadText: # 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
  
  ```
  
  
  ---
  
  