Comments 33
Начинайте скрипты на bash с set -e -u сразу после shebang, тогда они будут падать от первой ошибки или undefined variable usage.
Подумайте серьезно о пересадке на Jenkins. Он просто чудо. Кривоват местами, но за 12 или около лет работы с ним ни разу не загнал меня в тупик.
Такое легко ловится на code review, если пользоваться kotlin dsl. А так teamlead должен бегать по всем шагам в интерфейсе, которые были изменены, и проверять что ничего не пропущено.
По поводу Jenkins — так и думаю. Благодаря teamcity я начал вести «чёрный список технологий», с которыми больше не соглашусь работать. В проектной работе это особенно актуально. Обычно есть стенд клиента, для доступа к которому нужно подключиться к VPN, потом по RDP к Windows серверу и только с него будет видно Linux машины (и никак иначе). В итоге у нас всё классно автоматизировано в teamcity, а у клиента мы из консоли запускаем команды. А так поднял Jenkins где нужно и всё.
Кстати, не сразу стало для меня очевидно, что в скриптах шибанг нужно ставить. Пару часов на отладку в первій раз потратил, пітаясь разобраться что не работает: баш-скрипт или подстановка параметров ТимСити
set -o pipefailтогда будет падать при возникновении ошибок в пайплайнах:
set -o pipefail
false | echo 'Hello world!'
echo rc: $?
>Hello world!
>rc: 1
В отличие от дефолтного поведения, где return code будет соответствовать последней команде в пайплайне и, таким образом, 'set -e' проигнорирует эту ошибку:
set +o pipefail
false | echo 'Hello world!'
echo rc: $?
>Hello world!
>rc: 0
Пока фатальный недостаток TeamCity как CI/CD системы для меня — по сути она CI система, CD там для галочки. Ведь там нет сущности "среда/контур/стенд/сервер/енв/хост/..." с персистентными свойствами типа номера последней залитой сборки, там нет, даже для статических енвов. Приходится мудрить с простынями параметров, артефактами и вечным башем, как-то её эмулируя и со страхом думать, что делать когда дойдёт до динамически разворачиваемых сред в том же AWS.
И да, назначать параметры сборки по разным триггерам позволило бы избежать копипасты и/или разбираться с шаблонами, но так или иначе создавая дублирующиеся сборки типа деплой на прод, деплой на дев, которые триггерятся с мастер или девелоп ветки и отличаются только наборами параметров.
Из досадных мелочей:
- нет шаблонов шагов сборки — множественное наследование шаблонов сборки так себе замена
- нет rsync деплоя
- нет докер/докер-композ деплоя
- нет возможности задать переменную окружения типа DOCKER_BUILDKIT=1 для шагов на докер-екзекуторе
P.S. Не хватило варианта для голосования "Использую TeamCity и столкнулся с разными проблемами", проголосовал за "с такими же", но только часть из них актуальна, а часть не обозначена в посте.
P.P.S. В связи с запуском JetBrains Space (очень неудобно гуглить, кстати) возникли сомнения по поводу будущего TeamCity в принципе. Их пытаются развеять, но получается только немножко снизить их градус словами "не беспокойтесь, развиваться будет и то, и то" — нет чёткого сравнения фич (включая роадмапы) Space CI/CD и TeamCity
И снова здравствуйте :)
нет шаблонов шагов сборки
Возможно, мета-раннеры тут помогут?
нет докер/докер-композ деплоя
Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?
нет чёткого сравнения фич (включая роадмапы) Space CI/CD и TeamCity
Сравнение сделаем, пока просто не успели. Хотя не уверен, что по фичам будет иметь смысл — скорее по ключевым направлениям, так как оба продукта активно развиваются, а у TeamCity еще и фора в 14 лет. Публичный роадмап TeamCity можно посмотреть здесь: https://www.jetbrains.com/teamcity/roadmap/. Кстати, параметры в зависимости от триггеров планируем в следующем году сделать.
Здравствуйте :)
Возможно, мета-раннеры тут помогут?
Да, что-то вроде этого имелось в виду. Хотя XML-конфиги, пробрасываемые вручную через локальную машину, явно не ожидалось как решение… Оно в репозиторий котлиновский попадёт?
Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?
Эти раннеры запускаются на хосте с агентом, я же про запуск на целевом сервере, до аналоге CLI раннера со скриптом типа
Отправил случайно и не успел отредактировать
Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?
Эти раннеры запускаются на хосте с агентом, я же про запуск на целевом сервере, для сценариев типа:
- триггернулись на новый таг в репе с исходниками
- сбилдили образ
- запушили в реестр с тагом
- дёрнули docker-compose up с подстановкой тега в. Дёрнули докер не на хосте с агентом, а на целевом сервере с заходом по ssh, как ssh-exec или в агенте, но с DOCKER_HOST=…
Поясню про мета раннеры. Мета раннер позволяет объединить несколько часто используемых шагов сборки в один, либо сильно упростить какой то из стандартных шагов приспособив его под конкретную ситуацию. Сам мета раннер хранится в виде XML файла, под папкой проекта, как и все другие сущности в TeamCity. В репозиторий с Kotlin DSL он попадёт тоже в виде XML. Хотя при использовании DSL не совсем понятно зачем использовать мета раннеры, так как Kotlin полноценный язык программирования и там и так полно способов переюзать настройки.
Спасибо за пояснения. Попробую как закончу пайплайны чтоб понять что часто переиспользуется.
Что до Котлина, то пока единственное место, где он мне встречается — продукты JetBrains, странно, да? ) Учусь потихоньку его читать и править помаленьку, типа параметр заменить или скрипт отредактировать. Но, как я понимаю, возможности переиспользования приведут к большим проблемам при попытках редактировать конфигурации через UI, надо делать выбор — или Котлин, или UI.
P.S. Ну и проблемы возникают при редактировании Котлина — какую-то ошибку допустишь и ТимСити не хочет загружать репозиторий с малопонятными сообщениями об ошибках, приходится git reset HEAD~1 && git push --force делать…
Мне показалось что и 2й и 3й пункты частично про невозможность запустить какую то сборку вне состава билд чейна. Знакомы ли вы с тем что можно сделать Re-run конкретного билда в составе билд чейина (тогда он не будет пересобирать зависимости), либо можно запромоутить какой то из билдов дальше по цепочке. Т.е. если у вас есть стенд с авто тестами, его можно запромоутить в билд тестирования, т.е. не обязательно запускать тестирование и надеяться что переюзается стенд.
3. Могу предположить что дублирование параметров возникает из за того что reverse.dep передаёт значение as is, не пытаясь разрезолвить его в том контексте где reverse.dep задан. Но если речь не про это, было бы здорово тут получить какие то детали.
7. Возможно лучше было использовать переменные окружения. они либо могут быть объявлены как пароль, либо могут ссылаться на парольный параметр. И с ними проще работать в shell скриптах.
8. Уточните пожалуйста в какой версии TeamCity наблюдаете проблему и новый это UI или обычный?
9. Вы используете какой то плагин для запуска Ansible шагов? Если так то проблема с error reporting может быть в нём. Насколько нам известно по умолчанию stderr не считается ошибкой, хотя можно и так настроить.
По Re-run — да, я в курсе про такую функциональность, используем в случае если нужно перезапустить именно упавшую сборку. Но когда в день набегает по 300-400 сборок, то бывает заморочно найти нужную. Понятно что есть теги и фильтр по веткам, но в случае если команда 40 человек и почти все запускают из develop, то так не сработает.
А из вкладки конкретной сборки, если осталась в браузере, вызвать её ещё раз нельзя.
Однако может я чего-то не понял, но бывает такой случай (может уже исправили): зависимая сборка упала и из-за «Snapshot dependency failed» падает и запускаемая. Делаешь re-run, он в диалоговом окне почёму-то подбирает по умолчанию упавшую, а не вариант «rerun all dependencies» и теперь всё 100% падает.
3. Я задаю новый параметр «Name: reverse.dep.DevServer.DUMP_DIR». Но это не позволяет автоматом проставить строки «Value» и «Spec» (в моём понимании в 1% случаев требуется чтобы эти параметры отличались). В итоге мне нужно после актуализации в зависимой сборке «Value» и «Spec» идти в сборку с reverse.dep и тоже обновлять.
В моём понимании реализовать можно так: «Value» и «Spec» блокируются, если указан reverse.dep, а при вызове «Run Custom Build» показано к какой сборке относятся какие параметры.
7. Да, хорошее предложение, спасибо. Мы пока пользуемая только configuration parameter, так как не сформировалось чёткого понимания когда лучше что использовать.
8. TeamCity Enterprise 2020.1.5 (build 78938). Это новый UI.
9. Нет, запускаем через «Command line». Пробовили плагин Ansible, но я не ощутил каких-то качественных изменений при его применении, так как вкладка «Ansible log» всегда была пустая, решили не плодить сущности. Мы не можем запускать в плагине через вариант «Executable», так как системная версия Ansible не та и не хватает пакетов, поэтому нужно в каждом шаге активировать venv. А отличие между «Ansible / Custom script» и «Command line» околонулевое.
Вообще же я бы посоветовал более детально обсудить ваш случай с зависимостями в нашем саппорте. Если вдруг язык это проблема, пишите по русски. Если у вас Enterprise license то смело можете рассчитывать на ответ.
3. Кажется я примерно понимаю о чём речь, попробую оформить тикет.
8. UI действительно может порождать много запросов, но как правило они не блокирующие. У нас есть несколько открытых performance проблем в новом UI (например youtrack.jetbrains.com/issue/TW-67720), но хорошая новость в том что есть прогресс и сейчас довольно много ресурсов вкладывается в то чтобы сделать его быстрым. Пока остаётся только потерпеть, должно стать лучше.
9. Чтобы лучше понимать use case, я правильно понимаю что у вас выставлена настройка:
Format stderr output as: error в command line шаге + выбран чекбокс an error message is logged by build runner на Failure conditions странице?
Можно использовать читерский способ передачи информации между двумя независимыми сборками.
Все настройки, которые Вы делаете в веб-интерфейсе, отражаются в конфигурационном xml-файле сборки.
В первой сборке, куда надо передать информацию, Вы заводите для этого конфигурационный параметр.
Другая сборка, которая информацию передаёт, одним из своих шагов правит конфигурационный xml-файл первой сборки, выставляя соответствующий конфигурационный параметр.
По мне такой способ напоминает вариант «ускорения» кода на C++ используя ассемблерные вставки. Это получается быстрее, но тот, кто будет после вас это поддерживать, будет очень недоволен :)
Да, есть публично доступный форум: https://teamcity-support.jetbrains.com/hc/en-us/community/topics/200366709-TeamCity-General-Topics
«Нюансы» использования TeamCity