Commit Datei von Jenkins workspace zu SVN

Können Sie uns ein paar mehr details? Was genau ist diese Datei und warum braucht es zu sein, sich als Teil von Ihr Jenkins-build? Was baut Ihr (Java? C++? .NET?) und wie baust du es?

Normal, man sollte das nicht alles unter Versionskontrolle außer Quelle - Dateien. Das ist, wenn Sie es bauen können, sollten Sie nicht setzen Sie es in die Versionskontrolle. Eine Menge Leute wie sich Ihr gebaut-code in Ihre version control system, aber dies ist in der Regel ein großer Fehler. Binär-Dateien sind viel größer und selten diff. Dies führt zu einem source-repository, das 90% kompilierten code-fast alle davon überflüssig. Problematisch ist dies vor allem mit der Subversion, die nicht (leicht) entfernen veralteter code.

Jenkins hat eine Funktion, mit der Sie Archiv deine Dateien für den einfachen Zugriff. Wir nutzen diese die ganze Zeit. Wir bauen unser code, und das Programm ist verfügbar in Jenkins für downloads. Noch besser, Jenkins löschen älteren builds (Sie können die letzten X-builds oder speichern nur baut, die jünger als X Tage). Und wenn Sie ein release candidate erstellen, können Sie lock , zu bauen, um zu verhindern, dass es gelöscht wird.

Immer noch, wenn Sie darauf bestehen, dies zu tun, gibt es mehrere Dinge, die Sie tun können, und Dinge, die Sie achten müssen:

1. Wenn Sie haben Jenkins setup automatisch erstellen jedes ändern, und Sie verpflichten sich, eine Veränderung in Ihrem version control system, Jenkins sehen, dass, und starten Sie ein neues bauen. Dann, Jenkins speichert die änderung, sieht den ändern, und tut das andere bauen. Stellen Sie sicher, schließen Sie die Dateien oder Verzeichnisse, die von Jenkins' Aspekt, wenn es tun sollten, eine zu bauen. Sie können dies angeben, wenn Sie geben Sie die URL der Kasse.

2. Anders als die meisten Versionskontrollsysteme Subversion wurde als client-unabhängig. Es gibt eine tatsächliche API für clients. Die standard-Subversion-Kommandozeilen-client ist nicht erforderlich Jenkins, so stellen Sie sicher, dass es installiert ist. Stellen Sie sicher, dass Sie einen client installieren kompatibel mit dem Jenkins gebaut in SVNKit client. Dies gilt insbesondere, seit Subversion 1.6, 1.7 und 1.8 alle nehmen Sie einen anderen client-format.

3. Können Sie mehrere build-Schritte zu dem build in Jenkins. Fügen Sie einfach ein neues shell-Skript oder batch-Skript Schritt, und fügen Sie in einem svn commit -m "comment of some sort" Schritt. Es ist ziemlich einfach zu tun ist, nachdem Sie gekümmert haben, die ersten zwei Punkte. Aber, bitte überlegen Sie genau, warum Sie dies tun.

Wie ich schon sagte, von 99,9999% der Zeit, Sie sollten nicht mit Jenkins zu verpflichten, Veränderungen, die Sie gebaut. Ich bin mir sicher, dass 0.0001% Grund vorliegt irgendwo, aber ich habe es nie gesehen. Wenn Sie wollen gebaut Dateien allgemein zugänglich für Ihre anderen Projekte verwenden Jenkin ' s Fähigkeit, Archiv gebaut-Dateien.

Wenn ein Produkt, das Jenkins baut benötigt ein anderes build verwenden, können Sie die Copy Artifact Plugin kopieren ein build-Artefakt auf eine andere Stelle, und dann Feuer aus, dass job. Noch besser, verwenden Sie ein release-repository-system. In Java können Sie mit einem Maven-release-repository wie Nexus oder Artifactory. Nutzen und bereitstellen der Artefakte auf diese repository, können Sie mit Efeu oder Maven oder Gradle. Wenn Sie Gebäude .NET, Blick auf Nuget.

InformationsquelleAutor David W.

Könnte man gezielt nutzen:

svn commit -username someuser -password %injected_password% 

injizieren Passwort in Build Environment dieser Befehl fügt Kennwörter zu dem build als Umgebungsvariablen

Watch out: das Kennwort ist sichtbar in der job-trigger-batch.

InformationsquelleAutor Ato