CruiseControl.NET Build schlägt fehl, wenn SVN nicht verfügbar ist

Wir haben ein SVN-Repository extern gehostet und unser Build-Server ist derzeit intern. Gelegentlich (wahrscheinlich 1 oder 2 Mal am Tag) kann der Erstellungsserver das SVN-Repository aufgrund eines Netzwerkausfalls, einer Zeitüberschreitung oder eines anderen zufälligen Grundes nicht finden. Bei einem extern gehosteten Repository ist dies schwer zu vermeiden, aber wenn es das SVN-Repository nicht findet, schlägt der Build fehl!CruiseControl.NET Build schlägt fehl, wenn SVN nicht verfügbar ist

Ich möchte einen Weg finden, um es einfach beim nächsten Intervall erneut zu versuchen und alle Fehler in Bezug auf ein nicht gefundenes Repository zu ignorieren. Weiß jemand wie ich das machen kann?

Ich habe meine Konfiguration als Referenz unten veröffentlicht.

<project name="MyProject" queuePriority="0"> 
<workingDirectory>C:\RemovedForPost</workingDirectory> 
<artifactDirectory>C:\RemovedForPost </artifactDirectory> 
<sourcecontrol type="svn"> 
    <trunkUrl>http://RemovedForPost \</trunkUrl> 
    <workingDirectory>source</workingDirectory> 
    <username>myuser</username> 
    <password>*****</password> 
</sourcecontrol> 
<triggers> 
    <intervalTrigger name="BuildAMinute" seconds="60" buildCondition="IfModificationExists" /> 
</triggers> 
<tasks> 
    <msbuild> 
    <executable>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable> 
    <workingDirectory>C:\RemovedForPost</workingDirectory> 
    <projectFile>C:\RemovedForPost\RemovedForPost.sln</projectFile> 
    <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
    <targets>Build</targets> 
    <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    <timeout>120</timeout> 
    </msbuild> 
    <nunit> 
    <path>C:\Program Files\NUnit 2.5\bin\net-2.0\nunit-console.exe</path> 
    <outputfile>C:\RemovedForPost.xml</outputfile> 
    <assemblies> 
     <assembly> RemovedForPost </assembly> 
    </assemblies> 
    <timeout>60</timeout> 
    </nunit> 
</tasks>

Dank

Quelle

2009-07-21 Odd

Auf jeden Fall lahm. Ich habe dieses Problem auch. +1. –

Korrektur. Alles, was Sie wollen, ist in den neuen Einstellungen

CruiseControl.NET docs

Sie können diese Funktion nicht einen Fehler melden, bis max gesetzt wiederholt. Also make max bei 3 und setze es so, dass es nur auf die Publisher-Einheit (dh die Build-Fail-Einheit) umschaltet, die das Limit erreicht. Also 1 oder 2 Fehler werden in Ordnung sein, aber dann 3 Fehler beim Build etwas falsch ist.

Quelle

2009-07-21 02:02:39 Alex

Nun, es würde nur einmal in 95% der Fälle versagen, nur zweimal in Folge die anderen 5%, so dass Trigger nicht viel Nutzen für mich bringen wird, aber wenn ich das nicht beheben kann, muss ich es bekommen los von CC.NET. Mit nur 1-2 Checkins pro Tag bekommen wir eine Fehlerrate von 50%. – Odd

Nun, ich weiß nicht wohin du gehen würdest. Es scheint ein Grundprinzip der Continuosu-Integration zu sein, dass, wenn Sie den Source-Control-Server nicht erreichen können, der Build fehlschlagen sollte. Gibt es ein System, an das Sie denken, dass Sie dies konfigurieren können? – Alex

Aber wenn Sie so viele Fehler haben, denken Sie nicht, dass Sie die Ursache Ihres Problems ansprechen sollten? Ich meine, das passiert mir manchmal, aber es ist normalerweise während geplanter Ausfallzeiten des SCC-Anbieters für Upgrades und dergleichen. –

CruiseControl.NET Build schlägt fehl, wenn SVN nicht verfügbar ist

Antwort

Verwandte Themen