Pull to refresh

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 где нужно и всё.

А, понятно. Я, к сожалению, уже давно не работал с TeamCity, но в Jenkins я для отладки создаю агента (jnlp или ssh) на виртуалке с prod-like конфигурацией (та же ось и версия Java/Python) прямо на своем PC и отлаживаюсь там.

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

Я, пока не понял, что в Jenkins по умолчанию sh, а не bash, тоже часто промахивался (но это не совсем, как у вас было, если я правильно понял).

В ТимСити, как я понимаю, по умолчанию /bin/sh для Linux-систем. В моём случае на Ubuntu хосте это был dash. Главное, что в логе ошибка была bad parameter substitution, которая навела меня на мысль, что "виновата" тимсити.

А в ssh-exec shebang игнорится в принципе — ещё полдня почти в минус (

Добавил бы еще
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

Нагуглил это на день раньше чем прочитал ваш комментарий :)


Плохо в ТимСити нет шаблона для скриптов как в IDE есть

На КДПВ персонаж в фильме-сказке был, ЕМНИП Ивана за пригрешения наказали, превратили в медведя. Вывод — нужно писать качественный код.

Пока фатальный недостаток 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=…

Вот эти шаги можно же сделать где угодно, например, на хосте с агентом:


  • триггернулись на новый таг в репе с исходниками;
  • сбилдили образ;
  • запушили в реестр с тагом.

А последний шаг запустить уже на целевом сервере. Зачем на рабочем сервере билдить образы?

Да речь не про билдить, речь про то, что нет раннера выполнения докера на целевом сервере для последнего шага, docker-exec какого-то по аналогии с ssh-exec.

Поясню про мета раннеры. Мета раннер позволяет объединить несколько часто используемых шагов сборки в один, либо сильно упростить какой то из стандартных шагов приспособив его под конкретную ситуацию. Сам мета раннер хранится в виде XML файла, под папкой проекта, как и все другие сущности в TeamCity. В репозиторий с Kotlin DSL он попадёт тоже в виде XML. Хотя при использовании DSL не совсем понятно зачем использовать мета раннеры, так как Kotlin полноценный язык программирования и там и так полно способов переюзать настройки.

Спасибо за пояснения. Попробую как закончу пайплайны чтоб понять что часто переиспользуется.


Что до Котлина, то пока единственное место, где он мне встречается — продукты JetBrains, странно, да? ) Учусь потихоньку его читать и править помаленьку, типа параметр заменить или скрипт отредактировать. Но, как я понимаю, возможности переиспользования приведут к большим проблемам при попытках редактировать конфигурации через UI, надо делать выбор — или Котлин, или UI.


P.S. Ну и проблемы возникают при редактировании Котлина — какую-то ошибку допустишь и ТимСити не хочет загружать репозиторий с малопонятными сообщениями об ошибках, приходится git reset HEAD~1 && git push --force делать…

По отсутствию CD — полностью согласен. На прошлой неделе решали проблему: как посмотреть что на каком сервере устанавливалось (так как появилось подозрение, что кто-то запустил что-то не там). В итоге добавили логгирование в БД, так как из teamcity эту информацию нереально получить.
Добрый день,

Мне показалось что и 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» околонулевое.
Насколько мне известно Re-run по умолчанию выбирает rebuild all failed dependencies. Причём это не относится только к зависимостям первого уровня, он анализирует все зависимости перед текущим билдом и сам определяет что нужно перебилдить. Если это не работает так, то это повод создать баг репорт.

Вообще же я бы посоветовал более детально обсудить ваш случай с зависимостями в нашем саппорте. Если вдруг язык это проблема, пишите по русски. Если у вас 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 странице?
По баг-репортам — спасибо, учту.

8. Хорошо :)

9. Нет, как раз всё наоборот. «Format stderr output as: warning» и не выбран чекбокс «an error message is logged by build runner».

Можно использовать читерский способ передачи информации между двумя независимыми сборками.
Все настройки, которые Вы делаете в веб-интерфейсе, отражаются в конфигурационном xml-файле сборки.
В первой сборке, куда надо передать информацию, Вы заводите для этого конфигурационный параметр.
Другая сборка, которая информацию передаёт, одним из своих шагов правит конфигурационный xml-файл первой сборки, выставляя соответствующий конфигурационный параметр.

Ого, не знал про такую чёрную магию. Видел, что все конфигурации в итоге хранятся в XML, если смотреть что было изменено. Однако это слишком опасный способ: как я понял никто не гарантирует стабильность «XML API» и можно что-то всё хорошо сломать при повышении версии teamcity.
По мне такой способ напоминает вариант «ускорения» кода на C++ используя ассемблерные вставки. Это получается быстрее, но тот, кто будет после вас это поддерживать, будет очень недоволен :)
А вообще существует какое-то сообщество Тимсити где можно задать свой вопрос? Я так и не смог найти ничего кроме багтрекера.
Работал с тремя инструментами для CICD — Gitlab CI, GitHub Actions и вот удалось познакомиться поближе с TeamCity. Для меня неоспоримым лидером по удобству, простоте и функциональности является Gitlab CI.
Only those users with full accounts are able to leave comments. Log in, please.