Ich versuche, Jenkins einzurichten, um von meinem SVN-Repo abzufragen und einen neuen Build zu starten, sobald er feststellt, dass ein Commit eingegangen ist. Ich habe den Polling-Teil funktioniert, aber das Gebäude ist ziemlich übereifrig und gerade jetzt Es wird jedes Mal neu erstellt, wenn es Abstimmungen gibt - ob es Änderungen gab oder nicht. Die Datei SCM-polling.log lautet:
%Vor%Die Konsolenausgabe von Jenkins sieht folgendermaßen aus:
%Vor%Die Repo-URL ist auf svn: //10.64.147.118: / svn / repos / conttest / trunk eingestellt, und ich habe Jenkins angewiesen, nicht versionierte Dateien zu löschen und dann vor dem Build zu aktualisieren. Der Arbeitsbereich enthält definitiv die Dateien im Repo, und der Build ist jedes Mal erfolgreich.
Irgendwelche Ideen, was das verursacht?
Also, ich habe herausgefunden, dass es scheint, dass das svn: // - Protokoll weder in Jenkins noch im SVN-Plugin unterstützt wird. Nachdem ich meinen SVN-Server so geändert habe, dass er http: // verwendet und diesen neuen Pfad in Jenkins einstellt, werden Builds nicht mehr ausgeführt, es sei denn, es gibt tatsächlich einen neuen Commit.
TL, DR: Verwenden Sie nicht svn: //, verwenden Sie stattdessen http: //.
Ich bin mir nicht sicher, was das verursacht, aber ich hatte in der Vergangenheit viele Probleme mit SCM-Abfragen. Ich habe herausgefunden, dass es besser ist, einen SVN-Post-Commit-Trigger zu schreiben, der die URL des Builds trifft, um ihn auszulösen. Dies eliminiert den Aufwand für das Abrufen und löst niemals einen Build aus, wenn keine Änderungen vorgenommen werden. Wenn Sie Lust auf etwas haben wollten, könnten Sie den Trigger sogar "intelligenter" machen und das Kompilieren bei Änderungen von Dateien wie readme.txt und ähnlichem vermeiden.
Wir hatten ein ähnliches Problem mit CVS, bei dem die CVS-Abfrage länger dauerte als die Zeit, zu der ich aufgefordert wurde, nach Änderungen zu fragen. Das heißt, es würde CVS drei Minuten dauern, um nach Änderungen zu fragen, aber ich sagte, es solle jede Minute abfragen. Dies sollte jedoch kein Problem mit Subversion sein.
Sie können einen Post-Commit-Hook als Feasoron verwenden, aber es gibt zwei Probleme mit diesem Ansatz:
>Die meisten Leute haben Subversion-Abfragen in Jenkins / Hudson und haben diese Probleme nicht, also hängt es wahrscheinlich mit etwas in Ihrem Setup zusammen.
Sehen Sie sich die Abfragelogs für jeden Build an und sehen Sie, warum Jenkins / Hudson glaubt, ein Update zu sehen (verfügbar in jedem Build als Link auf der linken Seite der Webseite). Schau dir auch die ersten Zeilen deiner Build-Konsole an und sieh nach, ob das irgendwelche Hinweise bietet.
Wenn Sie es immer noch nicht herausfinden können, aktualisieren Sie Ihre Frage mit einigen der Abfrageprotokolle und das könnte uns helfen zu verstehen, warum Sie diese Probleme haben.
Es könnte ein Problem mit dem SVN-Plugin sein. Siehe hier Ausgabe 10222 .
Tags und Links jenkins svn hudson hudson-plugins