Bramki lintowania i szablonów w CI

Uszkodzony chart powinien zatrzymać Państwa pipeline, a nie produkcyjny klaster. Bramki CI pozwalają odrzucać nieprawidłowe charty natychmiast po otwarciu pull requestu. 🛡️

Polecenie helm lint wykonuje statyczne kontrole chartu: sprawdza jego strukturę, wymagane pola oraz typowe problemy związane z dobrymi praktykami, nie dotykając żadnego klastra.

Lint wykrywa brakujące pole w Chart.yaml, szablon, którego nie można sparsować, lub ikonę, która nie jest adresem URL. Działa szybko i nie wymaga połączenia z Kubernetes.

Należy dodać --strict, aby ostrzeżenia lint również kończyły uruchomienie niepowodzeniem. W CI kompilacja powinna zakończyć się błędem przy każdej wątpliwej sytuacji, zamiast wyświetlać ostrzeżenie, którego nikt nie przeczyta.

Należy przekazać -f, aby wykonać lint z wartościami, których dane wydanie rzeczywiście użyje. Chart może być poprawny bez wartości, a mimo to przestać działać po połączeniu z wartościami produkcyjnymi.

Po pomyślnym przejściu lint należy uruchomić helm template, aby lokalnie wygenerować wszystkie manifesty. Jeśli tworzenie szablonów się nie powiedzie, pipeline zatrzyma się, zanim cokolwiek trafi do Kubernetes.

Lint sprawdza tylko podstawowe elementy, natomiast helm template w pełni oblicza logikę szablonów Go. Literówka w range lub wartość nil ujawni się tutaj, a nie dopiero w czasie wdrożenia.

Oba polecenia zwracają niezerowy exit code w przypadku błędu. Programy uruchamiające CI automatycznie odczytują ten kod i oznaczają zadanie jako nieudane, blokując scalanie zmian.

Należy przekierować wygenerowany wynik do kubeval lub kubeconform, aby potwierdzić jego zgodność z rzeczywistymi schematami Kubernetes. Pozwala to wcześnie wykryć nieprawidłową nazwę pola.

Należy połączyć bramki w jednym zadaniu, aby błąd zatrzymywał pozostałe kroki. W większości programów uruchamiających operator && zatrzymuje wykonanie po pierwszym niezerowym kodzie wyjścia, dzięki czemu informacja zwrotna pojawia się szybko.

Te kontrole należy uruchamiać przy każdym pull request, a nie tylko podczas scalania zmian. Recenzenci widzą wtedy pomyślną kontrolę potwierdzającą, że chart nadal generuje się poprawnie.

Każdą zmianę należy sprawdzać za pomocą helm lint --strict, a następnie helm template; opcjonalnie można również sprawdzić schemat wygenerowanego wyniku. Nieprawidłowe charty kończą działanie kompilacji, a nie klastra. ✅