2010-08-01 4 views
5

Mein Arbeitsplatz benutzt Hudson für seine täglichen Builds, mit mehreren Build-Slaves (ein Linux, ein Windows, ein Mac), die unsere komplette Codebase von svn auschecken und unsere App jeden Tag um Mitternacht bauen. Das alles funktioniert ziemlich gut.Wie kann ich sicherstellen, dass alle meine Hudson Build Slaves die gleiche SVN Revision für den täglichen Build auschecken?

Es gibt ein gelegentliches Problem, das jedoch passiert ... manchmal arbeitet ein Entwickler zu spät und checkt kurz nach Mitternacht eine Änderung an svn ein. Wenn dies auftritt, ist es möglich, dass einige der täglichen Build-Slaves ihre 'svn-Prüfung' ausführen, bevor die svn-Festschreibung verarbeitet wird, während andere Build-Slaves dies tun, nachdem die Festschreibung verarbeitet wurde. Wenn dies geschieht, haben wir verschiedene Revisionen, die auf verschiedenen Plattformen erstellt wurden, z. Der Mac-Build könnte ein Build der SVN-Revision 5555 sein, während der Windows-Build ein Build der SVN-Revision 5556 ist. Das ist schlecht, da wir wollen, dass alle täglichen Builds für einen bestimmten Tag auf derselben Codebasis basieren.

Ich denke, eine Möglichkeit, dies zu vermeiden, ist es, Entwicklern zu verbieten, Svn zwischen 11.30 Uhr und 12.30 Uhr zu verpflichten, aber ich würde eine elegantere Lösung bevorzugen, die nicht auf das Verhalten der Entwickler angewiesen ist. Ist dort eines? Insbesondere, wenn es eine Möglichkeit gibt, Hudson zu sagen, dass er die Revision des Codes, die um Mitternacht des aktuellen Tages aktuell war (z. B. "svn co -r {" das-aktuelle-Datum "}"), auschecken sollte HEAD, ich denke, das könnte den Trick bringen.

Gibt es einen einfachen Weg, um dieses Problem zu lösen?

+0

Starten Sie den Build um 1 Uhr? :) –

+0

lol, das war ein guter. Ich hoffe, sie haben kein Problem, so dass die Entwickler bis 13 Uhr oder später da sind. ;) –

Antwort

3

Die Lösung hängt ein wenig davon ab, wie Sie die Builds starten. Wenn alle Timer gestartet sind, können Sie alle gleichzeitig starten. Das Risiko, dass Sie verschiedene Revisionen haben, ist minimal. Eine elegantere Version besteht darin, dass ein Job alle Buildjobs auslöst, die die Revision als Parameter übergeben. Wenn der Build nicht zu lang ist, können Sie einen Job erstellen, der die Revision an alle anderen Jobs weiterleitet.

EDIT: zur Zeit die folgenden nicht von Hudson unterstützt (1,376)

ich auch einen schönen svn book gefunden. Es besagt, dass Sie die Revision durch ein Datum in geschweiften Klammern ersetzen können. So können Sie <svn-url>@{00:00} in Ihrer Jobkonfiguration ausprobieren.

+0

Der @ {00:00} Trick ist ordentlich; Leider funktioniert es nicht über den Java-basierten Svn-Client, der in Hudson eingebettet ist. Eine andere Überlegung ist, wenn Ihr Repository svn: externals verwendet, dann glaube ich, dass die externen auch mit der falschen Revision abgerufen werden können. – jdkoftinoff

+0

Ich habe das gerade auch bemerkt. :( –

0

Eine weitere Idee fand ich nützlich ist die gleiche Quelle dir unter Sklaven zu teilen und ein svn up Befehl haben, schneiden diese die Zeit von svn update nach unten, und auch von den Schmerzen der Synchronisation freigeben.

Ich benutze NFS auf Linux-Maschinen, auch sshfs wird funktionieren.

Verwandte Themen