Почему Teamcity посылает прерывание клавиатуры, чтобы убить мою сборку?

Question

У меня запущена сборка в TeamCity, только один шаг сборки: запуск BAT-файла. TeamCity иногда убивает мою сборку с помощью (двойного) клавиатурного прерывания, и я понятия не имею, почему. Выход в конце сборки выглядит так:

Running build failed.
Error:
NUnit test failed (7).
Starting BuildFailureTarget: recover
Uninstalling service under test..Terminate batch job (Y/N)? 
^C
Process exited with code -1073741510

Эта сборка запускает некоторые интеграционные тесты через NUnit после установки службы Windows с базой данных SQL. Если какой-либо из тестов завершается неудачно, сценарий сборки (который использует FAKE, F #'s Make) выполняет некоторую очистку - удаляет службу, разрушает базу данных. Это тот же код очистки, который выполняется при прохождении сборки, отличается только имя цели (recover). Кажется, что TeamCity убивает сборку только в случае неудачи некоторых тестов. Следует отметить, что сообщение «Удаление тестируемой службы» поступает из подпроцесса, на котором выполняется деинсталлятор. Это по-прежнему происходит, даже если мы отключаем несколько условий сбоя, так что сборка (спонтанно) проходит после неудачного завершения нескольких тестов (мы не используем Java, поэтому мы предполагаем, что один из них не имеет значения):

Я не могу понять, почему TeamCity убивает мою сборку, прежде чем это будет сделано. Как мне выяснить, что заставит TeamCity выдавать это прерывание?

Answer 1

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

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