2009-06-23 6 views
4

Ich erhalte eine Ausnahme von Cruise Control, weil ich keine Verbindung zum Server herstellen kann. Wenn ich jedoch einen Build erzwinge, funktioniert es gut. Ich habe auch versucht, mit dem Repobrowser ohne Probleme eine Verbindung zum Server herzustellen, also weiß ich, dass der Server läuft. Ich verwende CCNET 1.4.4 und SlikSVN 1.5.3. Unten ist die Ausnahme von der CCNET-Protokoll:CruiseControlException beim Verbinden mit der Quellcodeverwaltung

ThoughtWorks.CruiseControl.Core.CruiseControlException: 
Source control operation failed: svn: OPTIONS of 'https://some-server.com/trunk': could not connect to server (https://some-server.com) . 
Process command: C:\Program\SlikSvn\bin\svn.exe log https://some-server.com/trunk -r "{2009-06-23T01:36:19Z}:{2009-06-23T07:20:25Z}" --verbose --xml --username ccnet --password auto --non-interactive --no-auth-cache 
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) 
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetModifications(IIntegrationResult from, IIntegrationResult to) 
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetModifications(IIntegrationResult from, IIntegrationResult to) 
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild) 
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to) vid ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request) 

Alle Ideen würden sehr geschätzt werden!

+0

Nun, es gibt Ihnen das Kommando dort. "C: \ Programme \ SlikSvn \ bin \ svn.exe-Protokoll https://some-server.com/trunk -r" {2009-06-23T01: 36: 19Z}: {2009-06-23T07: 20: 25Z } "--verbose --xml --username ccnet --password auto --non-interactive --no-auth-cache" Ich würde versuchen, das in eine Eingabeaufforderung einzugeben und zu sehen, ob Sie eine hilfreichere Fehlermeldung erhalten. –

+0

Ich habe das auch getan und es gibt mir überhaupt keine Fehler. Alles funktioniert gut. –

+1

@Kristalloffer -> Wenn Sie es von der Befehlszeile aus ausgeführt haben, haben Sie denselben svn-Benutzer verwendet, den Sie konfiguriert haben? Ich finde es nur schwer zu glauben, dass es keine Verbindung herstellt, wenn Sie eine Verbindung über die Befehlszeile herstellen können. Wenn alles gleich ist, sollte der Erfolg von Hand Erfolg im CC haben. Da ist keine Magie drin ... – Alex

Antwort

5

Ich habe endlich wieder funktioniert und das habe ich gemacht.

  • Set maxSourceControlRetries bis 10 in meinem CCNET-config
  • Set sourceControlErrorHandling zu ReportOnEveryRetryAmount in meinem CCNET-config
  • auf die neueste Version von Client CollabNet Switched

Wie sich herausstellt, CCNET Ich habe SourceControl-Fehler wie diese in früheren Versionen geschluckt, so dass ich vielleicht schon Probleme hatte, bevor ich auf CCNET 1.4.4 updaten konnte, mir aber nicht bewusst war.

Vielen Dank für Ihre Kommentare!

+0

Hey, ich habe das gleiche Problem, aber nicht sicher, wie es wirklich zu beheben ist. Haben Sie nach den Änderungen, die Sie gemacht haben, nicht mehr die Ausnahme oder ist es tatsächlich ein Zwangsaufbau, erhalten Sie die Ausnahme? – user62958

+0

Ich könnte immer noch den Fehler bekommen, aber nicht mehr als 10 Mal in Folge, da ich keine Fehlermeldungen mehr von CruiseControl erhalte. Der Build scheint jetzt in Ordnung! Und nein, ich zwinge den Build nicht jedes Mal. –

+0

Ich habe das gleiche Problem. Ich habe die ersten beiden Dinge vor langer Zeit gemacht, und ich weiß, dass es die 'Frequenz' reduziert, aber es löst nicht das eigentliche * Problem *. Ich denke, es hat etwas damit zu tun, dass der Hostname oder keine Netzwerkverbindung aufgelöst werden kann. Wir sehen es normalerweise nachts, also kann ein Server "schlafen" oder was auch immer und es kann keine Verbindung herstellen. Wie auch immer, es ist ein lästiges Problem und ich kann es anscheinend nicht vollständig reparieren :( – Razzie

0

Ich habe dieses Problem beim Ändern der SVN-Quelle in der Nähe eines Code-Freeze aufgetreten. Ich erstelle ein Release-Tag und ändere den Source-Control-Bereich, um auf das Tag und nicht auf den Entwicklungszweig zu verweisen. Das Build-Arbeitsverzeichnis enthält jedoch weiterhin die Quelle für den Entwicklungszweig einschließlich aller SVN-Metadateien. Dies löst die Ausnahme aufgrund der Kollision von SVN-Quellen aus (der ursprüngliche Dev-Zweig und das neue Release-Tag).

In diesem Fall ist die einfache Lösung, den Code (Verzeichnisse und alle) aus dem Build-Arbeitsverzeichnis zu löschen, und CruiseControl ziehen Quelle für den Entwicklungszweig von der neuen Position.

Hier ist ein Auszug aus einer ccnet.config-Datei, die geändert wurde, um dieses Problem zu verursachen. Sieht es bekannt aus?

<sourcecontrol type="multi"> 
    <sourceControls> 
     <svn> 
      <!-- 
      <trunkUrl>https://svn/Engineering/Applications/Quasar/branches/TeamRowdy</trunkUrl> 
      --> 
      <trunkUrl>https://svn/Engineering/Applications/Quasar/tags/REL-TeamRowdy-RC1-2013.07.17.003</trunkUrl> 
      <workingDirectory>Quasar</workingDirectory> 
      <cleanUp>true</cleanUp> 
      <forceUpdate>true</forceUpdate> 
     </svn> 
     <svn> 
      <!-- 
      <trunkUrl>https://svn/Engineering/Applications/Acme/branches/TeamRowdy</trunkUrl> 
      --> 
      <trunkUrl>https://svn/Engineering/Applications/Acme/tags/REL-TeamRowdy-RC1-2013.07.17.003</trunkUrl> 
      <workingDirectory>Acme</workingDirectory> 
      <cleanCopy>true</cleanCopy> 
     </svn> 
    </sourceControls> 
</sourcecontrol> 
Verwandte Themen