Comments 5
Хочется поставить жирный дизайк, за бездарную статью. Официальная документация к argo-cd намного увлекательнее чем эта породия на статью.
.
Затем мы перейдем к SOURCE части. Нам нужно указать URL-адрес git. Я собираюсь использовать пример, расположенный по адресу. Если вы перейдете в этот репозиторий, вы обнаружите, что там нет ничего, кроме простого Golang приложения с папкой с именем «helm»
А куда делась папка helm? Самого главного в этой статье мне не хватает (
Дак посмотри историю и откатись на нужный коммит ;-)
Вот последний в котором она существовала:
https://github.com/IronCore864/go-hello-http/tree/0b6e9bf3e694a46ea1f0fe5f0328ce8e7d367034
>Нет ничего плохого в Jenkins, на что я указывал в моей предыдущей статье о CI
Ну да, ну да. В Jenkins нет ничего плохого, если им не пользоваться. А если пользоваться, то полезут многочисленные проблемы и вообще работа с ним сродни алхимии. Ресурсы жрет "как не в себя", чтобы добиться какого то продвинутого функционала, нужно ставить кучу плагинов. Сначала нужно изучить тонну информации, найти нужный плагин. Начинаешь его ставить, а он уже Deprecated и надо искать другое решение. Ок, поставил другой плагин, решил одну задачу. Ставишь другой плагин, он получает запросы от сторонней системы (видно в логах), но дальше не запускает что нужно. Почему так? У одних плагинов выяснить так и не получилось, просто не работает, магия. У других плагинов выясняется, что по умолчанию он конфликтует с другим плагином и нужно делать какие то дополнительные настройки, чтобы они друг друга не блочили.
И такой алхимии - полно, вся работа с дженкинсом состояит из такой алхимии. Сегодня этот рецепт работал, завтра уже что то изменилось и опять все не работает. На выяснение причин уходят много много человекочасов. А в Gitlab-CI все упирается тупо в объем изученного тобой материала. Если что то не работает, то просто еще чуть почитай официальную и поймешь, почему все не пашет. исправил и потом все работает годами без разной алхимии.
Argo CD: готов к труду и обороне в Kubernetes