Wie kann man die Ausgabe einer ausführbaren Datei mit CruiseControl.Net ignorieren?

Question

Ich verwende ein kleines Dienstprogramm zum Suchen und Ersetzen namens fart.exe (ja, fart, wie in Find and Replace Text) als Teil meines CC-Builds. Funktioniert prima.

Das Problem ist, dass FART während der Arbeit einen kleinen ASCII-Spinner anzeigt, der aus Pipe, Bindestrich, Slash... | / - . Es gibt keine Möglichkeit, diesen Spinner zu unterdrücken, und CC hält diese kleinen Symbole für Fehlermeldungen und der Build schlägt fehl. Ich habe es versucht:

• Hinzufügen dieser Symbole als Erfolgsexitcodes in CC -- gleiches Ergebnis, offenbar funktionieren nur Ints
• Der Aufruf von fart über eine Batch-Datei mit ECHO OFF - gibt immer noch den Spinner aus und führt zum Scheitern des Builds

Haben Sie eine andere Idee?

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

Answer 1

Ich hatte dieses Problem auch mit Furz und einem KI-System. Anstatt die ausführbare Datei neu zu kompilieren, habe ich die Ausgabe nach NUL umgeleitet.

Zuerst habe ich festgestellt, dass die Spinner-Ausgabe auf stderr war. Dann fügte ich "2>NUL" an die Befehlszeile an, die fart aufrief, und es furzte nicht länger einen Spinner auf stderr.

Hat sonst noch jemand bei diesem letzten Satz das Bild eines Windrades in einer stinkenden Brise vor Augen?

Answer 2

In meinem Fall musste ich fart.exe von einer Batch-Datei aus starten, die später von Jenkins ausgeführt wurde, und ich habe Folgendes herausgefunden.

fart.exe gibt in %errorlevel% die Anzahl der Ersetzungen zurück, die durchgeführt wurden. Wenn diese Anzahl 1 ist, ist das der Wert von %errorlevel%, was bedeutet, dass Jenkins mit dem Exit-Code 1 fehlschlägt.

Um dies zu beheben, habe ich meiner Batch-Datei folgendes hinzugefügt:

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%

Durch Hinzufügen von ECHO OFF zum Aufruf von fart.exe wurde der %errorlevel%-Wert wieder auf 0 gesetzt, aber dadurch waren die von fart durchgeführten Ersetzungen nicht mehr erfolgreich.

Ich hoffe, das hilft jemandem!

Answer 3

Danke für die Antworten, aber am Ende habe ich zwei Dinge getan:

• Ich habe die Textersetzungs-App (fart) ohne den Spinner neu kompiliert. Auch nachdem ich dies tat, war CC immer noch aus irgendeinem Grund fehlgeschlagen, so dass ich...
• Batch-Executables wurden in die msbuild-Datei statt in die cc-Config-Datei verschoben. CC wurde dann erfolgreich gebaut.

Ich bin mir sicher, wenn ich CC besser verstanden hätte, hätte ich es besser machen können, aber für den Moment ist das der Trick!

Answer 4

Ich bin auf das gleiche Problem gestoßen. Ich habe herausgefunden, dass FART errorlevel = 1 zurückgibt, wenn es erfolgreich ist, und errorlevel = 0, wenn es fehlgeschlagen ist mit "Zugriff verweigert" oder "Datei nicht gefunden" usw. Erzwingen Sie also errorlevel = 0, wenn es erfolgreich läuft, und erzwingen Sie errorlevel = 1, wenn es fehlschlägt. Bei mir funktioniert das.

Answer 5

Die successExitCodes-Liste soll eine Liste von Ints sein. Hier sind ein paar Vorschläge:

1. Erstellen Sie eine kleine Stapeldatei, die die ausführbare Datei ausführt, und rufen Sie Ihre Stapeldatei (anstelle von fart) über die ausführbare Aufgabe auf.
2. Versuchen Sie, die Nicht-Ints aus den successExitCodes zu entfernen und überprüfen Sie, welchen Exit-Code fart zurückgibt... manchmal erhalten Sie unerwartete Rückgabewerte, wie bei der Verwendung von robocopy.