[Housekeeping] Add kubeconform check to validate generated manifests in CI

[lowc1012]

Motivation: Why do you think this is important?

Once we modify helm charts and execute make helm, this command just generates/updates k8s manifests & helm docs.
These manifests may not have been validated against the schema for Kubernetes.

Kubeconform is a Kubernetes manifest validator; it takes all the manifests and validates them against the schema from the Kubernetes repository.

Goal: What should the final outcome look like, ideally?

Add kubeconform check in helm-charts.yaml github action wf. At least we should have to validate all manifests under deployment and docker/sandbox-bundled/manifests when we want to modify them.

Describe alternatives you've considered

First, we can check if make helm is executed once PR includes changes to charts. Second, we validate manifests under deployment and docker/sandbox-bundled/manifests.

Propose: Link/Inline OR Additional context

1. https://github.com/yannh/kubeconform
2. https://www.fairwinds.com/blog/gitops-best-practices-and-the-kubernetes-guardrails-you-need

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[dosubot]

🤖

Adding a kubeconform check to the .github/workflows/helm-charts.yaml GitHub action workflow would indeed be beneficial for validating generated manifests in your CI. This would be particularly useful when modifications are made to the helm charts under deployment and docker/sandbox-bundled/manifests.

kubeconform is a tool that validates Kubernetes manifests against the Kubernetes API's schemas. This ensures that the manifests are correctly structured and adhere to the expected specifications of the Kubernetes resources they define. This validation can help catch errors and inconsistencies early in the development process, before the manifests are applied to a Kubernetes cluster.

To integrate kubeconform into your workflow, you would add a new step after the "Build helm chart" step and before the "Publish Helm chart to GHCR" step. This new step would involve installing kubeconform (if not already available in your CI environment), generating the Kubernetes manifests from the Helm chart using helm template, and then running kubeconform against these generated manifests.

Here is an example of how you might add such a step:

      - name: Validate generated manifests with kubeconform
        working-directory: charts
        run: |
          # Install kubeconform
          curl -sL https://github.com/yannh/kubeconform/releases/download/v0.4.12/kubeconform-linux-amd64 -o kubeconform
          chmod +x kubeconform
          
          # Generate Kubernetes manifests from Helm chart
          helm template ${{ matrix.chart }} --output-dir ./manifests
          
          # Validate manifests under 'deployment' and 'docker/sandbox-bundled/manifests'
          ./kubeconform -summary -strict ./manifests/deployment
          ./kubeconform -summary -strict ./manifests/docker/sandbox-bundled/manifests

This example assumes that the generated manifests are placed under ./manifests/deployment and ./manifests/docker/sandbox-bundled/manifests relative to the charts directory. You might need to adjust the paths based on where helm template actually outputs the manifests in your workflow.

Adding this validation step can significantly improve the reliability and correctness of the Kubernetes manifests produced by your Helm charts, catching potential issues early in the CI process.

For more information about kubeconform, you can refer to its GitHub repository. For more details about the current structure of the .github/workflows/helm-charts.yaml GitHub action workflow in the flyte repository, you can refer to the flyte repository.

Sources

• .github/workflows/helm-charts.yaml

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[lowc1012]

I'm not sure if we have to check the manifests generated via kustomize

[pingsutw]

@lowc1012 Feel free to open a PR.

[lowc1012]

#take