Как игнорировать вывод из исполняемого файла при сборке CruiseControl.Net?

Question

Я запускаю небольшую утилиту для поиска и замены под названием fart.exe (да, fart, как в разделе «Найти и заменить текст») в рамках моей сборки CC. Работает отлично.

Проблема в том, что FART во время работы отображает небольшой счетчик ASCII, состоящий из трубы, тире, косой черты ... | / -. Нет способа подавить этот счетчик, и CC думает, что эти маленькие символы являются сообщениями об ошибках, и сборка не удалась. Я пробовал:

• добавление этих символов в качестве последовательных символов в CC - тот же результат, по-видимому, работают только целые числа
• Вызов пердеть через командный файл с отключенным ECHO - он по-прежнему выводит счетчик и вызывает сбой сборки

Есть еще идеи?

<exec>
<executable>C:\fart.exe</executable>
<buildArgs>myfile.txt string1 string2</buildArgs>
<successExitCodes>1,0</successExitCodes>
</exec>

Answer 1

Я также столкнулся с этой проблемой с пердеть и система CI. Вместо того, чтобы перекомпилировать исполняемый файл, я перенаправил вывод в NUL.

Сначала я определил, что выход спиннера был на stderr. Затем я добавил «2> NUL» к командной строке, которая вызвала пердеть, и он больше не пукнул спиннер на stderr.

Кто-нибудь еще получил вертушку в виде вонючего бриза из этого последнего предложения?

Answer 2

В моем случае мне нужно было запустить fart.exe из командного файла, который позже запустил Jenkins, и вот что я обнаружил.

fart.exe возвращает в% errorlevel% количество выполненных замен. Если это значение равно 1, это будет значение% errorlevel%, что означает наличие кода выхода 1, что заставит Дженкинса потерпеть неудачу.

Чтобы это исправить, вот что я добавил в свой командный файл:

REM standard "fart.exe" error-handling block; 9009 (missing program) is bad, anything else above 0 is OK and should be reset to 0 for standard handling
if ERRORLEVEL 9009 (
    REM do nothing
) else (
    if ERRORLEVEL 1 CMD /C EXIT 0
)

REM ensure that we exit with the current errorlevel context...
exit %errorlevel%

При добавлении ECHO OFF к вызову fart.exe значение% errorlevel% снова становится равным 0, но при этом замены, выполняемые fart, перестают быть успешными.

Надеюсь, это кому-нибудь поможет!

Answer 3

Я столкнулся с той же проблемой. И, обнаруженный FART возвращает errorlevel = 1, если он успешен, и возвращает errorlevel = 0, когда он потерпел неудачу с «отказано в доступе» или «файл не найден» и т. Д. Итак, принудительно установите errorlevel на 0, когда он выполняется успешно, и принудительно установите его на 1, когда это терпит неудачу. У меня это работает.

Answer 4

Спасибо за ответы, но в итоге я сделал две вещи:

• Перекомпилировано приложение для замены текста (пердеть) без счетчика. Даже после этого CC по какой-то причине все еще не работал, поэтому я ...
• Перемещенные пакетные исполняемые файлы в файл msbuild вместо файла конфигурации cc. Затем ЦК успешно построен.

Я уверен, что если бы я лучше понимал CC, я мог бы пойти по этому пути лучше, но сейчас это помогает!

Answer 5

Эта строка, кажется, работает с помощью пердеть:

<exec program="fart.exe" commandline="${filename} 1.0 1.1" verbose="true" failonerror="false" />

Однако я не уверен, можно ли обработать ошибку failonerror иначе

Answer 6

Для приложений командной строки вы можете перенаправить вывод в файл, используя символ «>». Вызов в ваше приложение будет выглядеть так:

fart.exe myfile.txt строка1 строка2> myoutput.txt

Добавление перенаправления к свойству buildArgs должно помочь.

Answer 7

Список successExitCodes должен быть списком целых чисел. Вот пара предложений:

1. Создайте небольшой пакетный файл, который запускает исполняемый файл, и вызовите ваш пакетный файл (вместо пердеть) с помощью исполняемой задачи.
2. Попробуйте удалить non-ints из successExitCodes и проверьте, какой код завершения возвращает fart ... иногда вы получаете неожиданные коды возврата, как при использовании robocopy.