Удаляем устаревшую feature branch в Kubernetes кластере

[FessAectan]

Благодарю!
Полезная штука.

[OkGoLove]

Jenkins-X делал примерно похожие вещи через CronJob, сверяя существующие Environments (CRD) с PR и если последний закрыт, то удаляли Helm release и namespace.

Возможно ли добавить поддержку Helm в такой оператор?

[dmytrostriletskyi]

Технически — не знаю, не работал с Helm на таком уровне. Но я находил операторы, у которых есть поддержка Helm. Например — github.com/apache/camel-k. В общем, это интересно, я поресерчу больше на этот счет, спасибо! :)

[dmytrostriletskyi]

Технически — не знаю, не работал с Helm на таком уровне. Но я находил операторы, у которых есть поддержка Helm. Например — github.com/apache/camel-k. В общем, это интересно, я поресерчу больше на этот счет, спасибо! :)

[wir_wolf]

Установил себе, вроде как норм, но есть один минус. Я в начале думал что система смотрит не на дату создания неймспейса, а на то, когда в него что-то деплоили. Было-бы классно если-бы в новом релизе можно было это учитывать, к примеру перебрать все контейнеры в неймспейсе, взять самый новый, и проверить его на временной лимит. Так-же было-бы не плохо сделать исключения

[dmytrostriletskyi]

Я об этом даже не думал так как у нас такой процесс был: создать namespace, он живет пару дней живет, удалить namespace полностью. Поэтому и оператор для этого сделал — удалить namespace полностью, а не конкретный ресурс в нем.

[wir_wolf]

Просто если тестирование задачи затянулось, это нужно потом пересоздавать неймспейс постоянно, а если там данные какие-то есть которые импортируются с другого хранилища