«Нюансы» использования TeamCity

    Картинка


    Всем привет.


    Статья написана в простом стиле "DevOps для домохозяек" от таких же домохозяек. В ней будет описано с какими неожиданностями можно столкнуться при настройке проекта в TeamCity. Также приведу рекомендации как эти проблемы можно обойти.


    Нижеописанное основано на моём двухлетнем опыте настройке TeamCity сборок, чтению баг репортов и обмене мнений с коллегами по цеху. Не претендую на истину в последней инстанции, так как в работе в основном использовался подход SDD (Stackoverflow Driven Development).


    Небольшая справка:


    • TeamCity — CI (Continous Integration) инструмент. "Аналог" Gitlab CI, Github Actions с прицелом на возможность полной настройки автоматизации из графического интерфейса.
    • Проект (Project) — агрегирующая сущность, в неё связываются несколько сборок. В TeamCity древовидная структура проект->подпроект->сборка с частичным наследованием настроек.
    • Сборка (Build) — Атомарная сущность автоматизации. Примеры сборок "Запуск автотестов", "Установка конфигурации", "Сборка дистрибутива". Каждая сборка состоит из нескольких шагов.
    • Шаг (Build step) — Описание "а что нужно делать" используя разные "runner type". Это может быть как простой Bash скрипт, так и запуск Docker контейнера.

    Вкратце по проекту TeamCity с которым я работаю:


    • ~30 сборок, шаги сборок состоят из вызовов Bash, Ansible и Python.
    • Никаких сборок Android приложений, Web проектов, Docker, k8s и прочего. Просто заказ облачных серверов, подъем базы данных из дампа, установка программ и конфигурации.
    • Настройка ведётся из графического интерфейса, без Kotlin DSL (переход на него в планах).

    Про достоинства инструмента я думаю можно почитать в официальной документации и маркетинговых материалах, нет смысла их здесь повторять. Перейдём сразу к "нюансам".


    1 Нельзя изменить параметры сборки при запуске по триггеру


    Сборки можно запускать по триггеру (внешнему событию). Триггеры могут быть разные: была завершена другая сборка, обновилась git ветка, cron задача. При этом в сборке можно задать параметры по умолчанию.


    Так вот: запуск по триггеру можно сделать только с параметрами по умолчанию. На эту проблему есть нерешённая задача 2008 года.


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


    Но мне возразят, что нужно использовать build chain (цепочку сборок). Окей, давайте посмотрим что там не так.


    2 Build chain or not — просто скопируй ещё сборки


    В случае вышеописанного кейса (заказ стенда + прогон автотестов) мы настраиваем build chain. В таком случае если нам нужен стенд, то мы его получаем из сборки запуска автотестов. Интуитивно понятно, не правда ли?


    Но тут приходит другая проблема: а как ещё раз запустить сборку автотестов (мы же её запускаем периодически для каждого стенда). Иииии никак. Ну точнее можно, но тогда будет заказан ещё один стенд (если у вас не решён полностью вопрос с идемпотентностью). Или нужно указать во вкладке зависимостей, что не запускай зависимую сборку ещё раз.


    Но как тогда брать имя стенда, на котором запускать автотесты? Если у нас две сборки отдельных, то мы указываем имя в параметрах. Если цепочка сборок — то проще всего использовать артефакт. А теперь если мы желаем запускать и отдельно, и вместе, то нужен специальный огород, который будет это всё обрабатывать. Осталось только представить, как будет "интересно" настраивать такой огород, когда у нас появится две разные сборки на заказ стенда (заказ идёт в разных облаках, разные программы), а сборка с запуском автотестов будет одна.


    К сожалению, я не смог найти "пруфов" решения, которое предлагают разработчики, но если мне не изменяет память оно было такое: для каждого случая создавайте отдельную сборку. По мне это решение приводит к дублированию кода и больше похоже на костыль. Итого можно констатировать: нельзя сделать так, чтобы одну сборку можно было запустить и в цепочке и отдельно.


    3 Переопределение параметров зависимой сборки


    Рассмотрим другой пример: у нас есть три зависимые последовательные сборки, которые связаны в build chain. Скажем заказ в облаке стенда, установка дампа базы данных и установка программ. Мы "интуитивно" запускаем сборку по установке программ и возникает вопрос: а как пробросить размер заказываемой машины в зависимой сборке? И тут нам на помощь приходит переопределение параметров.


    Теперь у нас в одном диалоговом окне по запуску сборке возникает 3*N параметров, которые никак не отличаются друг от друга. Ещё стоит учитывать, что описание и параметры по умолчанию таких параметров не копируются, их нужно копировать отдельно. Особенно это "радует", когда эти описания и значения меняются. Их тогда нужно будет обновлять в N местах, если сборки можно вызывать из разных мест как в нашем случае. Например, нужен человеку только стенд с дампом базы данных, он тогда вправе заказать его со второй сборки. А там в параметрах версия дампа устаревшая, в отличие от последней сборки цепочки, и пойдёт разбор полётов на полдня почему дамп кривой.


    И конечно тут не будет никакой валидации, что вы не ошиблись в имени переопределяемого параметра, всё в лучших традициях YAML Developer'ов.


    4 Конфигурация сборки может быть только одна


    Проблема не относится к Kotlin DSL (у меня нет опыта его использования, не могу сказать насколько эта проблема действительно решается). Если мы настраиваем сборки в графическом интерфейсе как настоящие домохозяйки, то сталкиваемся со следующей проблемой: а как плавно поменять настройки проекта, так чтобы это не коснулось пользователей?


    Первый и самый простой вариант: объявить технологические работы и править "на горячую". Второй вариант: скопировать сборку в отдельное место и делать изменения в ней (наш вариант).


    Потом нужно после внесения изменения в основную ветку кода и в сборке как-то проинформировать всех пользователей, чтобы они обновили свою ветку кода. В общем не будьте как мы — используйте Kotlin DSL.


    Рекомендация: не архивируйте/удаляйте старые сборки, а обновляете их после внесения изменений в основную ветку кода. Всегда найдутся люди, у которых ссылки на сборки хранятся где-то в закладках и если вы поменяется ID сборки, то все ссылки побьются.


    5 TeamCity API


    Я думаю многие здесь знакомы с "главными" 4 метриками DevOps. И TeamCity кажется идеальным местом, чтобы собрать всю информацию хотя бы о половине из них ("Deployment Frequency" и "Lead Time for Changes").


    Иии вот нельзя в API быстро узнать процент упавших сборок, частоту запуска и причины падения. Да, там есть какие-то дашборды, но информация в них именно та, которая не нужна. То есть вот начали у нас падать все сборки на основной ветке, и мы можем только вручную "Assign investigation", либо придумывать как реализовывать такой инструмент в каждой сборке. Не очень удобно.


    Однако, в чём хорош API — так это в формировании build chain из-за вышеперечисленных недостатков с "нативным" способом. В таком случае можно сборки создавать для независимого запуска. А их связывание делать в отдельной сборке с запуском тупого Python скрипта. И много кто так обходит проблему.


    6 При запуске Bash скрипта проверяется только результат последней команды


    Есть у нас простой скрипт, написанный в интерфейсе:


    ./command_1.sh # always fail
    
    ls # always success

    В таком случае этот шаг сборки будет всегда зелёный. Но если мы добавим мантру:


    ./command_1.sh # always fail
    
    if [ $? -ne 0 ]; then
      echo "##teamcity[buildProblem description='Build failed']"
    fi
    
    ls # always success

    И тогда уже шаг будет красным, и сборка дальше не пойдёт (тут уже как выставлен "Execute step"). Иными словами, всегда нужно учитывать особенность работы Bash скриптов.


    7 Работа с шифрованными параметрами сборки


    В TeamCity можно добавить параметры-секреты, такие как пароли и API ключи. Чтобы такие данные не утекли, в логах сборки ищутся значения таких параметров и заменяются на символы *. И возникает следующий нюанс: а если нам эти параметры нужно записать в другой файл. Команда echo в таком случае не сработает — фильтр перехватит. В итоге мы пришли к следующему варианту:


    cat > constants.json <<- EOM
    {
        "key": "%value%"
    }
    EOM

    Задача, в которой это понадобилась, была следующая. Есть Python скрипт, который выполняет запросы к нескольким системам, и вся его конфигурация сохранена в JSON. Как к нему подать секреты? Можно через командную строку, но тогда у нас растекается конфигурация сразу по четырём местам: JSON, командная строка, значение по умолчанию в скрипте и ещё значение по умолчанию в параметре TeamCity. Поскольку скрипт должен быть тупым и одноразовым, то решили максимально упростить: всю конфигурацию втащить в JSON. JSON прям с вписанными именами параметров TeamCity сохраняем в репозиторий и копируем как есть в шаг сборки. В итоге мы сразу формируем нужный JSON и не разбираемся какой параметр, где нужен.


    8 Скорость прогрузки графического интерфейса


    Это будет очень субъективный пункт. Поскольку основная работа по настройке проводится в интерфейсе (для тех кто не пользуется связкой Kotlin DSL + TeamCity API), то производительность работы пропорционально скорости работы этого интерфейса. А он ооочень медленный. Я постарался в меру своих интеллектуальных способностей замерить скорость прогрузки и вот какие цифры получил (был использован браузер Firefox и инструмент Network).


    • Загрузка окно проекта со всеми сборками и вызов окна запуска сборки
      • load: 9.87 s
      • DOMContentLoaded: 4.92 s
      • Finish: 34.39 s
      • Size/transferred size of all requests: 10.69 MB / 2.42 MB
      • Requests: 345
    • Загрузка окна отдельной сборки и вызов окна запуска сборки
      • load: 4.59 s
      • DOMContentLoaded: 1.27 s
      • Finish: 27.42 s
      • Size/transferred size of all requests: 11.53 MB / 2.23 MB
      • Requests: 120

    Время Finish — до момента как у меня появляется возможность запустить сборку. Так как после этого ещё в фоне прогружается страница и идут запросы. Полминуты чтобы просто запустить одну сборку, неплохо?


    9 Информация по упавшей сборке


    Это будет ещё один субъективный пункт. Для каждой сборки есть вкладка Overview. В ней в случае падения сборки указывается ошибка. И эта ошибка в 99% случаев определяется неправильно. В нашем случае (может у кого по-другому) — ошибка определяется как "первое, что попало в stderr", хотя было бы логичнее сделать "последнее, что попало в stderr". В случае Ansible это всегда будет какой-нибудь "WARNING: Deprecation setting...". И в итоге это вызывает стабильный поток вопросов у людей слабо знакомых с TeamCity. Пусть лучше вообще там ничего не писалось.


    10 Вечные проблемы с агентами


    Здесь я бы хотел написать про все проблемы, которые связанные с агентами сборки (Build agents). Как известно в TeamCity есть master сервер, который выполняет роль планировщика, а сами сборки запускаются на отдельных серверах. И нужно уметь правильно с этими агентами работать (обслуживать), TeamCity тут мало что может сделать.


    Первая проблема — удаление агентов. У агентов чаще всего есть какой-то срок жизни, их лучше не делать долгоживущими, иначе потом появляется дрейф конфигурации. Например, кто-то поменял JAVA_HOME и понеслось. И вот это удаление может прилетать вообще неожиданно. Планировщик выдал агента для тяжеловесной ночной десятичасовой сборки. Но ночью чаще всего проводятся все работы по обслуживанию и какой-то сервис, не проверив что там с агентом просто его грохает. Мы так и не победили эту проблему (администрированием TeamCity занимается отдельная "команда").


    Вторая проблема — закончившееся место на агенте, либо неработающая базовая утилита. Пересекается с первым пунктом, но тут "веселее". Запускаем сборку, на самом первом шаге это всё падает и агент снова бодро готов браться за новую работу. Мы раздражённо запускаем сборку заново и по великому везению попадается тот самый агент и по новой. "Но у нас же есть великая настройка по выбору агента!" — скажете вы и будете правы. Только один нюанс: а если у нас build chain? Тутуту руру тутуту, а оказывается, что выбрать агент можно только на текущую сборку, на зависимые может браться какой угодно и мы знаем какой будет выбран по закону подлости. Но это в случае, если вы не выставили при установке зависимой сборки "Run build on the same agent". Но вы же выставили, правда?


    Третья проблема — дрейф конфигурации на агентах. На агентах должно быть неизменяемое окружение (то, что не должно быть root прав, я думаю объяснять не надо). Кто-то поменял переменную окружения, поменял локальные пути до утилит и понеслось. Начинаешь после каждого такого случая перестраховываться и потом у тебя 90% сборки — это подготовка агента к твоему print("Hello, World!").


    И конечно зайти на агент и интерактивно разбираться в чём там проблема не получится (в моём конкретном случае). Ещё лучше, когда на локальном линуксе всё отрабатывает. В общем "кто дебажил непонятную проблему на билд агентах — тот в цирке не смеётся".

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Хотелось бы узнать есть ли у кого ещё проблемы с использованием CI инструментов по похожим проблемам (или есть ещё интереснее случаи)

    • 26,4%Использую другой CI и не страдаю14
    • 3,8%Использую другой CI и страдаю ещё больше2
    • 17,0%Использую TeamCity и столкнулся с такими же проблемами9
    • 41,5%Использую TeamCity, полёт нормальный22
    • 11,3%Какой ещё CI, собираем локально по инструкции в Word6

    Комментарии 31

      0
      Трюк для отладки агентов — используйте reverse shell (например отсюда pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet) чтобы получить терминал на нём.
        0
        Посмотрел, выглядит то что нужно, спасибо.
        +3

        Начинайте скрипты на bash с set -e -u сразу после shebang, тогда они будут падать от первой ошибки или undefined variable usage.
        Подумайте серьезно о пересадке на Jenkins. Он просто чудо. Кривоват местами, но за 12 или около лет работы с ним ни разу не загнал меня в тупик.

          0
          Согласен, обычно кейс выглядит так: есть один шаг с правильным скриптом, который хочется разнести на два отдельных шага. Вырезаем конкретно нужную часть и объявления в начале забываем (их там обычно не одно).
          Такое легко ловится на code review, если пользоваться kotlin dsl. А так teamlead должен бегать по всем шагам в интерфейсе, которые были изменены, и проверять что ничего не пропущено.

          По поводу Jenkins — так и думаю. Благодаря teamcity я начал вести «чёрный список технологий», с которыми больше не соглашусь работать. В проектной работе это особенно актуально. Обычно есть стенд клиента, для доступа к которому нужно подключиться к VPN, потом по RDP к Windows серверу и только с него будет видно Linux машины (и никак иначе). В итоге у нас всё классно автоматизировано в teamcity, а у клиента мы из консоли запускаем команды. А так поднял Jenkins где нужно и всё.
            0

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

            0

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

              0

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

                0

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

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

                О, думал я всё про shell знаю. Век живи — век учись. Спасибо.

                  0

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


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

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

                  Пока фатальный недостаток TeamCity как CI/CD системы для меня — по сути она CI система, CD там для галочки. Ведь там нет сущности "среда/контур/стенд/сервер/енв/хост/..." с персистентными свойствами типа номера последней залитой сборки, там нет, даже для статических енвов. Приходится мудрить с простынями параметров, артефактами и вечным башем, как-то её эмулируя и со страхом думать, что делать когда дойдёт до динамически разворачиваемых сред в том же AWS.


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


                  Из досадных мелочей:


                  • нет шаблонов шагов сборки — множественное наследование шаблонов сборки так себе замена
                  • нет rsync деплоя
                  • нет докер/докер-композ деплоя
                  • нет возможности задать переменную окружения типа DOCKER_BUILDKIT=1 для шагов на докер-екзекуторе

                  P.S. Не хватило варианта для голосования "Использую TeamCity и столкнулся с разными проблемами", проголосовал за "с такими же", но только часть из них актуальна, а часть не обозначена в посте.


                  P.P.S. В связи с запуском JetBrains Space (очень неудобно гуглить, кстати) возникли сомнения по поводу будущего TeamCity в принципе. Их пытаются развеять, но получается только немножко снизить их градус словами "не беспокойтесь, развиваться будет и то, и то" — нет чёткого сравнения фич (включая роадмапы) Space CI/CD и TeamCity

                    +1

                    И снова здравствуйте :)


                    нет шаблонов шагов сборки

                    Возможно, мета-раннеры тут помогут?


                    нет докер/докер-композ деплоя

                    Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?


                    нет чёткого сравнения фич (включая роадмапы) Space CI/CD и TeamCity

                    Сравнение сделаем, пока просто не успели. Хотя не уверен, что по фичам будет иметь смысл — скорее по ключевым направлениям, так как оба продукта активно развиваются, а у TeamCity еще и фора в 14 лет. Публичный роадмап TeamCity можно посмотреть здесь: https://www.jetbrains.com/teamcity/roadmap/. Кстати, параметры в зависимости от триггеров планируем в следующем году сделать.

                      0

                      Здравствуйте :)


                      Возможно, мета-раннеры тут помогут?

                      Да, что-то вроде этого имелось в виду. Хотя XML-конфиги, пробрасываемые вручную через локальную машину, явно не ожидалось как решение… Оно в репозиторий котлиновский попадёт?


                      Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?

                      Эти раннеры запускаются на хосте с агентом, я же про запуск на целевом сервере, до аналоге CLI раннера со скриптом типа


                        0

                        Отправил случайно и не успел отредактировать


                        Можно здесь подробнее, пожалуйста? Полагаю, с Docker и Docker Compose раннерами вы знакомы? Имеется в виду что-то другое?

                        Эти раннеры запускаются на хосте с агентом, я же про запуск на целевом сервере, для сценариев типа:


                        • триггернулись на новый таг в репе с исходниками
                        • сбилдили образ
                        • запушили в реестр с тагом
                        • дёрнули docker-compose up с подстановкой тега в. Дёрнули докер не на хосте с агентом, а на целевом сервере с заходом по ssh, как ssh-exec или в агенте, но с DOCKER_HOST=…
                          0

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


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

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

                            0

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

                          0

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

                            0

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


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


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

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

                        Мне показалось что и 2й и 3й пункты частично про невозможность запустить какую то сборку вне состава билд чейна. Знакомы ли вы с тем что можно сделать Re-run конкретного билда в составе билд чейина (тогда он не будет пересобирать зависимости), либо можно запромоутить какой то из билдов дальше по цепочке. Т.е. если у вас есть стенд с авто тестами, его можно запромоутить в билд тестирования, т.е. не обязательно запускать тестирование и надеяться что переюзается стенд.

                        3. Могу предположить что дублирование параметров возникает из за того что reverse.dep передаёт значение as is, не пытаясь разрезолвить его в том контексте где reverse.dep задан. Но если речь не про это, было бы здорово тут получить какие то детали.

                        7. Возможно лучше было использовать переменные окружения. они либо могут быть объявлены как пароль, либо могут ссылаться на парольный параметр. И с ними проще работать в shell скриптах.

                        8. Уточните пожалуйста в какой версии TeamCity наблюдаете проблему и новый это UI или обычный?

                        9. Вы используете какой то плагин для запуска Ansible шагов? Если так то проблема с error reporting может быть в нём. Насколько нам известно по умолчанию stderr не считается ошибкой, хотя можно и так настроить.
                          +1
                          Добрый день.

                          По 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» околонулевое.
                            0
                            Насколько мне известно 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 странице?
                              0
                              По баг-репортам — спасибо, учту.

                              8. Хорошо :)

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

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

                            0
                            Ого, не знал про такую чёрную магию. Видел, что все конфигурации в итоге хранятся в XML, если смотреть что было изменено. Однако это слишком опасный способ: как я понял никто не гарантирует стабильность «XML API» и можно что-то всё хорошо сломать при повышении версии teamcity.
                            По мне такой способ напоминает вариант «ускорения» кода на C++ используя ассемблерные вставки. Это получается быстрее, но тот, кто будет после вас это поддерживать, будет очень недоволен :)
                            0
                            А вообще существует какое-то сообщество Тимсити где можно задать свой вопрос? Я так и не смог найти ничего кроме багтрекера.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое