Teamcity запускает шаги сборки, даже если тесты не работают

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

Последний шаг моей конфигурации сборки развертывает мой сайт, который я не хочу делать, если какой-либо из моих тестов не работает.

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

На вкладке "Условия сбоя сборки" я проверил следующие параметры в разделе "Сбой сборки", если:

-build process exit code is not zero
-at least one test failed
-an out-of-memory or crash is detected (Java only)

Это не работает - даже если тесты не пройдут, TeamCity разворачивает мой сайт, почему?

Я даже попытался добавить дополнительное условие сбоя сборки, которое будет искать конкретный текст в журнале сборки (а именно "Test Run Failed." )

При просмотре завершенного теста на обзорной странице вы можете увидеть сообщение об ошибке против последней сборки:

"Не удалось выполнить тестовый прогон". текст появился в журнале построения

Но он все равно развертывает его в любом случае.

Кто-нибудь знает, как это исправить? Похоже, что проблема длилась долгое время, здесь.

По-видимому, существует обходное решение:

До сих пор мы не рассматриваем эту функцию как очень важную, так как существует очевидное обходное решение: script может проверить необходимое условие и не создавайте артефакты, настроенные в TeamCity.

например. a script может перемещать артефакты из временного каталога в каталог, указанный в TeamCity, как публикация артефактов только из перед финишем и в случае успешной операции сборки.

Но мне непонятно, как это сделать, и это не похоже на лучшее решение. Любая помощь была оценена.

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

Это было полезно для установки зависимости вверх.

Ответ 1

Это известная проблема с TeamCity 7.1 (см. http://youtrack.jetbrains.com/issue/TW-17002), которая была исправлена в TeamCity 8.x + (см. этот ответ).

TeamCity различает неудавшийся сборку и неудачный шаг сборки. В то время как сбой unit test приведет к сбою сборки в целом, к сожалению, TeamCity по-прежнему считает успешный шаг теста успешным, поскольку он не возвращает ненулевой код ошибки. В результате последующие шаги будут продолжены.

Было предложено множество обходных решений, но я обнаружил, что они либо требуют нетривиальной настройки, либо компрометации при тестировании TeamCity.

Однако, рассмотрев предложение от @arex1337, мы нашли простой способ заставить TeamCity делать то, что мы хотим. Просто добавьте дополнительный шаг сборки Powershell после существующего тестового шага, который содержит следующий встроенный script (заменяя YOUR_TEAMCITY_HOSTNAME вашим фактическим хостом/доменом TeamCity):

$request = [System.Net.WebRequest]::Create("http://YOUR_TEAMCITY_HOSTNAME/guestAuth/app/rest/builds/%teamcity.build.id%")
$xml = [xml](new-object System.IO.StreamReader $request.GetResponse().GetResponseStream()).ReadToEnd()
Microsoft.PowerShell.Utility\Select-Xml $xml -XPath "/build" | % { $status = $_.Node.status }

if ($status -eq "FAILURE") {
    throw "Failing this step because the build itself is considered failed. This is our way to workaround the fact that TeamCity incorrectly considers a test step to be successful even if there are test failures. See http://youtrack.jetbrains.com/issue/TW-17002"
}

Этот встроенный PowerShell script просто использует API-интерфейс TeamCity REST для того, чтобы спросить, считается ли сама сборка в целом неудачной (переменная %teamcity.build.id%" будет заменена TeamCity фактическим идентификатором сборки, когда шаг выполняется). Если сборка в целом считается неудачной (скажем, из-за отказа теста), то этот PowerShell script выдает ошибку, заставляя процесс возвращать ненулевой код ошибки, который приводит к тому, что сам отдельный этап сборки будет считается неудачным. В этом случае последующие шаги могут быть предотвращены.

Обратите внимание, что этот script использует guestAuth, для которого требуется, чтобы гостевая учетная запись TeamCity была включена. В качестве альтернативы вы можете использовать httpAuth вместо этого, но вам нужно будет обновить script, чтобы включить имя пользователя и пароль TeamCity (например, http://USERNAME:[email protected]_TEAMCITY_HOSTNAME/httpAuth/app/rest/builds/%teamcity.build.id%).

Итак, с помощью этого дополнительного шага все последующие шаги, установленные для выполнения "Только если все предыдущие шаги были успешными", будут пропущены, если есть предыдущие неудачи unit test. Мы используем это, чтобы предотвратить автоматическое развертывание, если какой-либо из наших тестов NUnit не будет успешным, пока JetBrains не устранит проблему.

Спасибо @arex1337 за идею.

Ответ 2

Чтобы предотвратить путаницу, эта проблема исправлена в Team City v8.x. Нам не нужны эти обходные пути.

Вы можете указать политику выполнения шага с помощью шага "Выполнение":

Только если статус сборки успешный - перед началом шага агент сборки запрашивает статус сборки с сервера и пропускает этот шаг, если состояние не выполнено.

https://confluence.jetbrains.com/display/TCD8/Configuring+Build+Steps

Конечно, вам нужно выполнить сбой сборки, если не удалось выполнить хотя бы один unit test:

https://confluence.jetbrains.com/display/TCD8/Build+Failure+Conditions

На странице "Условия сбоя сборки" в разделе "Сбой сборки" укажите, когда TeamCity выйдет из строя:

по крайней мере один тест не выполнен.. Установите этот флажок, чтобы пометить сборку как неудачную, если сборка завершилась неудачно, по крайней мере, одним тестом.

Ответ 3

Это (как вы уже выяснили), известная проблема с TeamCity, есть набор связанных вопросов в своем Отслеживании проблем. Эта проблема, как мы надеемся, будет решена в следующей версии TeamCity (версия 8.x)

В то же время способ, которым мы определили решение проблемы (для версии 6.5.5), заключался в том, чтобы загрузить файл результатов теста в качестве части последующих шагов. Затем он анализировался, чтобы проверить наличие каких-либо ошибок при тестировании, вернуть код ошибки и, следовательно, правильно разбить сборку (выполнить любую очистку, необходимую нам как часть этого сбоя), которая, вероятно, сработает для вас.

Ответ 4

Сбой сборки TeamCity не означает, что он остановит сборку и опубликует артефакты, если ваша сборка предоставит выходные данные сборки, как требуется TeamCity. Он только обновит статус сборки должным образом.

Но вы можете очень хорошо остановить процесс сборки, изменив свою конструкцию script, чтобы остановить сборку при сбое тестового примера. Если вы используете MSBuild, тогда ContinueOnError="false" сделает это.

Ответ 5

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

Это было полезно для установки зависимости вверх.