Мы используем TeamCity для нашего CI-сервера и недавно начали использовать его DSL на основе Kotlin для определения конфигураций сборки в коде и фиксации их в git.
Вчера мы добавили новый проект, создав его в Котлине. Когда мы запустили репо, оказалось, что оно работает без ошибок, и в конце дня мы получили успешную сборку.
Однако сегодня утром все сборки во всех проектах, а не только в новом проекте, выдают следующие сообщения об ошибках: Failed to apply changes from VCS to project settings (revision c1a8904f01408c77d86794e9d276321ba11ae4d8): Configs generator runs longer than 120 seconds. Please fix the errors in VCS and commit again. Эта ошибка генерируется в самом начале сборки, а остальная часть сборки, похоже, проходит успешно даже после ее создания.
Сообщение об ошибке не появляется в Google, и я не вижу ничего плохого в Kotlin локально. Я сделал что-то не так в конфигурации моего проекта? Почему вчера сработало?
Ответ оказался связан с нашим решением виртуализации - AWS EC2 - и размером экземпляра нашего сервера TeamCity - t2.medium. Инстансы T2 являются «пакетными», в то время как другие типы экземпляров, такие как экземпляр M4, являются «фиксированными».
Экземпляры с пакетной загрузкой имеют медленный базовый минимальный уровень производительности, и каждый час они получают «кредиты», которые позволяют им работать с большим количеством ресурсов ЦП, чем базовый уровень. Когда экземпляры новые или они не постоянно используют ЦП, у них обычно достаточно кредитов ЦП для быстрой работы на более высоком уровне производительности, но когда эти кредиты исчерпаны, экземпляр будет работать очень медленно на базовом уровне производительности.
Вот что случилось с нами. Очевидно, базовый уровень производительности был настолько медленным, что не мог сгенерировать конфигурацию TeamCity из Kotlin в пара минут для наших очень скромных потребностей (7 конфигураций сборки в 3 проектах) на базовом уровне производительности, поэтому все сборки терпели неудачу.
Как только мы изменили наш сервер TeamCity на использование более производительного размера экземпляра, TeamCity снова смогла быстро сгенерировать свою конфигурацию из Kotlin, и наша проблема была решена.
В качестве альтернативы использованию более мощной машины вы можете увеличить тайм-аут 120 секунд, установив внутреннее свойство teamcity.versionedSettings.configsGeneratorTimeoutSeconds на любое большее значение секунд, перейдя в https://your.teamcity.instance/admin/admin.html?item=diagnostics&tab=properties, нажав Edit internal properties а затем установив значение, например, на teamcity.versionedSettings.configsGeneratorTimeoutSeconds=600.