Publikowanie chartów z zadania release

Po otagowaniu wydania pipeline powinien spakować chart i go opublikować, aby członkowie zespołu oraz klastry mogły pobrać nową wersję. 📦

Ogranicz krok publikowania tak, aby uruchamiał się dla tagu wersji, a nie przy każdym commicie. Dzięki temu repozytorium chartów nie będzie zawierać tymczasowych kompilacji deweloperskich.

Pole version w pliku Chart.yaml musi zwiększać się przy każdej publikacji. Helm i rejestry OCI odrzucają ponowne publikowanie istniejącej, niezmiennej wersji.

Polecenie helm package pakuje katalog chartu do archiwum .tgz z wersją w nazwie, utworzoną na podstawie nazwy i wersji chartu.

Współczesny Helm wysyła charty do rejestrów OCI, takich jak GHCR, czyli w to samo miejsce, w którym znajdują się obrazy kontenerów. Najpierw uwierzytelnij interfejs CLI.

Użyj helm push, aby wysłać plik .tgz do ścieżki repozytorium OCI. Chart można teraz instalować bezpośrednio za pomocą odwołania oci://.

W przypadku repozytorium HTTP ponownie wygeneruj index.yaml, aby klienci mogli znaleźć nową wersję chartu po przesłaniu pliku tgz.

Uwierzytelnij zadanie za pomocą krótkotrwałego tokenu z sekretów CI, a nie osobistego hasła zapisanego na stałe w pliku pipeline.

Narzędzie chart-releaser pakuje charty i aktualizuje indeks hostowany w GitHub Pages, co jest popularnym sposobem udostępniania chartów bez własnego serwera.

Opcjonalnie podpisz archiwum podczas wykonywania zadania, aby odbiorcy mogli zweryfikować jego pochodzenie. Podpisywanie naturalnie pasuje do tego samego kroku wydania co wysyłanie.

Ustaw appVersion na wersję aplikacji, którą wydajesz, jednocześnie zwiększając wersję chartu. Uczciwe utrzymywanie obu wartości ułatwia odbiorcom wybór właściwej kompilacji.

Zadanie wydania ma już spakowany plik tgz. Które polecenie publikuje go w rejestrze OCI?

Po utworzeniu tagu zwiększ wersję, wykonaj helm package, a następnie wyślij chart do rejestru OCI lub zaktualizuj index.yaml. Nowe charty są publikowane bez żadnych ręcznych czynności. ✅