Поясню про мета раннеры. Мета раннер позволяет объединить несколько часто используемых шагов сборки в один, либо сильно упростить какой то из стандартных шагов приспособив его под конкретную ситуацию. Сам мета раннер хранится в виде XML файла, под папкой проекта, как и все другие сущности в TeamCity. В репозиторий с Kotlin DSL он попадёт тоже в виде XML. Хотя при использовании DSL не совсем понятно зачем использовать мета раннеры, так как Kotlin полноценный язык программирования и там и так полно способов переюзать настройки.
Насколько мне известно 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 странице?
Мне показалось что и 2й и 3й пункты частично про невозможность запустить какую то сборку вне состава билд чейна. Знакомы ли вы с тем что можно сделать Re-run конкретного билда в составе билд чейина (тогда он не будет пересобирать зависимости), либо можно запромоутить какой то из билдов дальше по цепочке. Т.е. если у вас есть стенд с авто тестами, его можно запромоутить в билд тестирования, т.е. не обязательно запускать тестирование и надеяться что переюзается стенд.
3. Могу предположить что дублирование параметров возникает из за того что reverse.dep передаёт значение as is, не пытаясь разрезолвить его в том контексте где reverse.dep задан. Но если речь не про это, было бы здорово тут получить какие то детали.
7. Возможно лучше было использовать переменные окружения. они либо могут быть объявлены как пароль, либо могут ссылаться на парольный параметр. И с ними проще работать в shell скриптах.
8. Уточните пожалуйста в какой версии TeamCity наблюдаете проблему и новый это UI или обычный?
9. Вы используете какой то плагин для запуска Ansible шагов? Если так то проблема с error reporting может быть в нём. Насколько нам известно по умолчанию stderr не считается ошибкой, хотя можно и так настроить.
Attach build history существует фактически для одного use case. Если вы храните настройки в DSL и решили поменять id некоторых конфигураций, то после применения DSL на сервере вы можете обнаружить что у этих конфигураций больше нет истории билдов. Так как история как раз к id и была привязана. Здесь как раз и используется Attach build history action для того чтобы найти потерянную историю и перепривязать её к нужной конфигурации. Action просто так не появляется, только если сервер видит что такая потерянная история есть. Мне кажется что Attach build history не совсем про ваш use case.
Тут противоречивые требования. С одной стороны хочется удалить что то, с другой хочется сохранить эти артефакты. Ну как вариант, можно артефакты перенести в другое место.
Либо, для релизов всегда делать копии проектов. Тогда релиз остаётся нетронутым, и продолжает работать как работал, а в транке/мастере всё переделывается. Как правило такой подход лучше потому что всегда должна быть возможность выпустить срочных хотфикс и для этого лучше оставлять релизные конфигурации нетронутыми, как они были в момент релиза.
Да, есть публично доступный форум: https://teamcity-support.jetbrains.com/hc/en-us/community/topics/200366709-TeamCity-General-Topics
Поясню про мета раннеры. Мета раннер позволяет объединить несколько часто используемых шагов сборки в один, либо сильно упростить какой то из стандартных шагов приспособив его под конкретную ситуацию. Сам мета раннер хранится в виде XML файла, под папкой проекта, как и все другие сущности в TeamCity. В репозиторий с Kotlin DSL он попадёт тоже в виде XML. Хотя при использовании DSL не совсем понятно зачем использовать мета раннеры, так как Kotlin полноценный язык программирования и там и так полно способов переюзать настройки.
Вообще же я бы посоветовал более детально обсудить ваш случай с зависимостями в нашем саппорте. Если вдруг язык это проблема, пишите по русски. Если у вас 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 странице?
Мне показалось что и 2й и 3й пункты частично про невозможность запустить какую то сборку вне состава билд чейна. Знакомы ли вы с тем что можно сделать Re-run конкретного билда в составе билд чейина (тогда он не будет пересобирать зависимости), либо можно запромоутить какой то из билдов дальше по цепочке. Т.е. если у вас есть стенд с авто тестами, его можно запромоутить в билд тестирования, т.е. не обязательно запускать тестирование и надеяться что переюзается стенд.
3. Могу предположить что дублирование параметров возникает из за того что reverse.dep передаёт значение as is, не пытаясь разрезолвить его в том контексте где reverse.dep задан. Но если речь не про это, было бы здорово тут получить какие то детали.
7. Возможно лучше было использовать переменные окружения. они либо могут быть объявлены как пароль, либо могут ссылаться на парольный параметр. И с ними проще работать в shell скриптах.
8. Уточните пожалуйста в какой версии TeamCity наблюдаете проблему и новый это UI или обычный?
9. Вы используете какой то плагин для запуска Ansible шагов? Если так то проблема с error reporting может быть в нём. Насколько нам известно по умолчанию stderr не считается ошибкой, хотя можно и так настроить.
Либо, для релизов всегда делать копии проектов. Тогда релиз остаётся нетронутым, и продолжает работать как работал, а в транке/мастере всё переделывается. Как правило такой подход лучше потому что всегда должна быть возможность выпустить срочных хотфикс и для этого лучше оставлять релизные конфигурации нетронутыми, как они были в момент релиза.