Публикация чартов из задания выпуска

Когда вы добавляете тег к выпуску, ваш конвейер должен упаковать чарт и опубликовать его, чтобы коллеги и кластеры могли получить новую версию. 📦

Ограничьте область действия шага публикации запуском по тегу tag версии, а не по каждому коммиту. Так в репозитории чартов не будут появляться временные сборки для разработки.

Поле version в Chart.yaml должно увеличиваться при каждой публикации. Helm и реестры OCI отклоняют повторную отправку существующей неизменяемой версии.

Команда helm package объединяет каталог чарта в архив .tgz с версией. Имя архива формируется из имени и версии чарта.

Современный Helm отправляет чарты в реестры OCI, например GHCR, где хранятся и образы ваших контейнеров. Сначала аутентифицируйте CLI.

Используйте helm push, чтобы отправить файл .tgz по пути репозитория OCI. Теперь чарт можно устанавливать напрямую по ссылке oci://.

Для HTTP-репозитория вместо этого заново сформируйте index.yaml, чтобы клиенты могли обнаружить новую версию чарта после загрузки tgz.

Аутентифицируйте задание с помощью краткоживущего токена из секретов CI, а не личного пароля, зашитого в файл конвейера.

Инструмент chart-releaser упаковывает чарты и обновляет индекс, размещённый в GitHub Pages, — это популярный способ раздавать чарты без собственного сервера.

При необходимости подписывайте архив во время задания, чтобы потребители могли проверить его происхождение. Подписание естественно выполняется на том же шаге выпуска, что и отправка.

Задайте appVersion версии выпуска приложения, которое вы публикуете, одновременно увеличив версию чарта. Если обе версии указаны корректно, потребителям проще выбрать нужную сборку.

В задании выпуска уже есть упакованный tgz. Какая команда публикует его в реестре OCI?

После появления тега увеличьте версию, выполните helm package, а затем отправьте чарт в реестр OCI или обновите index.yaml. Новые чарты публикуются без ручных действий. ✅