Contrôles lint et template dans l’intégration continue

Un paquet défectueux doit faire échouer votre chaîne d’intégration, pas votre cluster de production. Les contrôles de la CI vous permettent de rejeter les paquets incorrects dès l’ouverture d’une demande de fusion. 🛡️

La commande helm lint effectue des vérifications statiques sur un paquet : elle contrôle sa structure, les champs obligatoires et les problèmes courants liés aux bonnes pratiques, sans toucher à aucun cluster.

Lint signale un champ manquant dans Chart.yaml, un modèle impossible à analyser ou une icône qui n’est pas une URL. Il est rapide et ne nécessite aucune connexion à Kubernetes.

Ajoutez --strict afin que les avertissements de lint fassent également échouer l’exécution. Dans la CI, vous voulez que la compilation échoue pour tout élément douteux, plutôt qu’un avertissement silencieux que personne ne lit.

Transmettez -f pour effectuer le lint avec les valeurs qu’un déploiement utilisera réellement. Un paquet peut être valide sans valeurs, puis échouer une fois vos valeurs de production fusionnées.

Une fois le lint réussi, exécutez helm template pour générer localement tous les manifestes. Si la génération échoue, la chaîne d’intégration s’arrête avant que quoi que ce soit n’atteigne Kubernetes.

Lint reste superficiel ; helm template évalue entièrement votre logique de modèles Go. Une faute dans une expression range ou une valeur nil apparaît ici, et non au moment du déploiement.

Les deux commandes renvoient un code de sortie différent de zéro en cas d’échec. Les exécuteurs de la CI lisent automatiquement ce code et marquent la tâche comme échouée, ce qui bloque la fusion.

Transmettez la sortie générée à kubeval ou kubeconform pour confirmer qu’elle correspond aux schémas Kubernetes réels. Vous détecterez ainsi rapidement un nom de champ incorrect.

Enchaînez les contrôles dans une seule tâche afin qu’un échec interrompe immédiatement la suite. Dans la plupart des exécuteurs, && s’arrête au premier code de sortie différent de zéro, ce qui accélère le retour d’information.

Déclenchez ces vérifications à chaque PR, et pas uniquement lors de la fusion. Les personnes chargées de la révision voient une vérification réussie qui confirme que le paquet est toujours généré correctement.

Quel contrôle évalue entièrement votre logique de modèles Go afin de détecter une expression range incorrecte ?

Contrôlez chaque changement avec helm lint --strict, puis helm template, en vérifiant éventuellement le schéma de la sortie. Les paquets incorrects font échouer la compilation, jamais le cluster. ✅