Wie, um zu bestimmen, Jenkins build-Verzeichnis von Ant?

Ich versuche zu migrieren, ein Ant-Skript, das ich schrieb, zu bauen und Bereitstellung von Projekten innerhalb der Jenkins-framework (statt ausgelöst von einem SVN post-commit-hook, das war die praktische Möglichkeit, die wir zunächst näherte sich die Dinge). Alles ist Super, außer ich brauche die Bühne-Dateien für die Bereitstellung Schritt, und ich möchte Sie zu Stopfen in der 'build' - Verzeichnis Jenkins schafft für den job (und da meine build.xml Leben in einer nicht-projektspezifischen Ordner, ${basedir} und ${user.dir} nicht-Punkt an die gewünschte Position).

innerhalb der Jenkins-Konfiguration, ich habe setup die folgenden:

[Jenkins]
Build Record, Root Directory: E:/builds/${ITEM_FULLNAME}

[Job-Spezifisch]
Build-Datei: C:\vc-tools\shadow\build.xml

beim ausführen eines bauen, das Skript ist entsprechend gestartet und ein job-spezifische build-Verzeichnis erstellt, z.B.

E:\builds\Test\2012-08-07_12-51-21

Möchte ich, um auf dieses Verzeichnis innerhalb des build-Skripts, aber kann nicht herausfinden, wie. einige der Dinge, die ich versucht habe:

 [echo] ${basedir}: C:\vc-tools\shadow
 [echo] ${user.dir}: C:\vc-tools
 [echo] ${env.workspace}: C:\Program Files (x86)\Jenkins\workspace\Test
 [echo] ${env.build_id}: 2012-08-07_12-51-21
 [echo] ${jenkins_home}: C:\Program Files (x86)\Jenkins
 [echo] ${BuildDir}: E:/builds/${ITEM_FULLNAME}

Hinweis: für das Letzte habe ich versucht, die vorbeifahrenden:

 BuildDir=E:/builds/${ITEM_FULLNAME}

als Eigenschaft konfiguriert, der die Aufgabe innerhalb von Jenkins (klar $ {} - Erweiterung nicht stattfinden, in diesem Kontext).

entsprechend der Dokumentation, gibt es keine speziellen environment-Variablen, die eingestellt werden, um die vollständige build-Verzeichnis Pfad -- ich kann fudge durch hardcoding der E:\builds root und Heften auf ${env.build_id}, aber hatte gehofft, es wäre ein einfacher Weg, um Zugriff auf den kompletten Pfad von etwas Jenkins macht (entweder ein Ant-Eigenschaft und einer environment-Variablen), um das Skript flexibler gestalten.

Ich bin mit Jenkins version 1.476.

Dank

  • Klingt wie Sie tun etwas sehr seltsam, das verstehe ich nicht. Warum ist das build.xml Datei liegt nicht im root-Verzeichnis des Projekts, das Sie erstellen? Normalerweise müssen Sie nur konfigurieren, die Jenkins ziehen Sie die Projekt-Dateien aus dem SCM-system und führen Sie dann das bauen... das Alles geschieht innerhalb des "Arbeitsbereichs" die Jenkins schafft für das build-job.
  • Warum müssen Sie das Verzeichnis? Könnten Sie relative Pfade verwenden, sicher
  • Ich habe einen generic build-Skript, dass verwendet werden kann für mehrere Projekte (es ist ein Projekt-spezifischen property-Datei, die das Skript nach unten zieht, um sich zu qualifizieren, was Ihr tut, aber ich sehe nicht den Wert, im moment, im kopieren der gleichen build.xml Datei über mehrere, ähnliche, Projekte).
  • wie bereits in der Frage, mein Skript ausgeführt wird, von einem Standort (C:\vc-tools\shadow), der Arbeitsbereich ist in eine andere (%JENKINS_HOME%\workspace\<job>) und das build-Ergebnis ist in einem weiteren (E:\builds\<job>\%BUILD_ID%). Ich gebe zu, es ist ein wenig seltsam, da Sie in der Regel, Haus build.xml innerhalb der Projekt-root - (oder einige relative Verzeichnis), in der Erwägung, dass habe ich mir in einer völlig anderen Lage. Ich kenne keinen Weg, um relativ-Adresse E:\builds aus C:\vc-tools\shadow (abgesehen von hardcoding natürlich).
  • Ich vermisste zeigen, dass Ihr build-Skript ist in einem anderen Verzeichnis. Bitte ignorieren Sie meinen Kommentar 🙂
InformationsquelleAutor rguilbault | 2012-08-07
  1. 12

    Es ist immer eine gute Idee für Ihr Projekt, um eine Kopie der build-Logik enthalten neben den Quell-code. Es macht das bauen mehr portabel Maschinen.

    Gesagt haben, dass, ist es auch durchaus üblich, um das setup-build-Dateien mit gemeinsamen build-Logik. ANT definiert die folgenden Aufgaben zur Unterstützung solcher Aktivitäten:

    Also eine mögliche Lösung ist, um zu speichern Sie eine einfache build.xml Datei im root Ihres Projekt-Verzeichnis:

    <project name="my project" default="build">

  <include file="C:\vc-tools\shadow\common-build-1.0.xml" as="common"/>

  <target name="build" depends="common.build"/>

</project>

    Hinweise:

    • Es ist eine gute Idee, verwenden Sie eine Revisionsnummer in der common-build-Datei-Namen. Dies hilft bei der Erhaltung der rückwärts-Kompatibilität mit anderen builds mit der älteren Logik.

    Update

    Wenn Jenkins läuft ein job legt eine Reihe von Umgebungsvariablen.

    Den folgenden ANT-Logik wird drucken Sie die Lage der Jenkins workspace-Verzeichnis:

    <property environment="env"/>

<target name="run">
    <echo message="Jenkins workspace: ${env.WORKSPACE}"/>
    <echo message="Job directory: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}"/>
    <echo message="Build data: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}/build/${env.BUILD_ID}"/>
</target>
    • dieses sieht wie es würde sehr hilfreich sein. eigentlich ist es somit einige zusätzliche Vorteile, die über den Umfang meiner ursprünglichen Frage -- danke für den Tipp! Ich nehme dies als Antwort, wenn ich eine chance haben, um zu testen, dass es tut, was ich erwarte, wird es (die einzige Frage die ich habe ist, ob ${basedir} oder ${user.dir} entspricht ${env.WORKSPACE} oder die wahren 'Aufbau' - Ordner, Jenkins legt)...
    • ok, also ich kann immer noch nicht bekommen eine Referenz auf das build-Verzeichnis, aber es passiert mir jetzt, dass ich brauche nicht darauf zu beziehen (es enthält Informationen über den build, Jenkins interessiert, braucht es nicht das Ziel für mein Bauvorhaben). das heißt, es wäre bequemer zu benutzen als staging-Bereich (den vollen Umfang dessen, was ich tun müssen, für legacy-Gründen, ist checkout/update der Arbeitsbereich vom SVN, suchen Sie nach kürzlich geänderten Dateien, und rufen Sie einen übersetzer gegen Sie zu erzeugen, um Objekt-Dateien -- die daraus resultierenden Quell-und Objekt-Dateien, die dann versandt werden müssen, um ein SMB-zugänglichen Ort).
    • ...den Arbeitsbereich-Speicherort ist, in denen der checkout/update geht, so will ich nicht zu sully es mit der Inszenierung der Dateien (die, btw, ich vergaß zu erwähnen, dass ich in einem anderen Baum-Struktur aus, wie Sie sich befinden-source-control). Kann ich erstellen, eine unabhängige Hierarchie (und ich könnte) wie E:\staging\${env.BUILD_TAG}, wenn Jenkins nicht automatisch sauber es für mich, wie es wäre die build-Verzeichnisses verwaltet (ich hatte gehofft, zu erstellen .Inszenierung Unterverzeichnis in ihm, der bringt mich zurück zu meiner ursprünglichen Frage/post).
    • nicht wirklich sicher, was Sie jetzt Fragen... - Staging-release-Artefakten, ist eine ganz andere Frage. Zum Beispiel habe ich den Einsatz des Nexus-staging-suite für die Verwaltung des Lebenszyklus von build-Artefakte. sonatype.com/books/nexus-book/reference/staging.html
    • was ist das Ziel für ein build? meine Erwartung war, dass ich einige Objekt-code-Dateien (post-übersetzung von Quelle)...in einem traditionellen layout, die Sie haben könnten, src und bin Ordner, wo die kompilierten src-Dateien landen im bin-Verzeichnis, die alle statt in den workspace-Ordner Jenkins prüft das Projekt auf-in meinem Fall, obwohl, Muss ich das layout ändern, der wird das ausgecheckte Projekt passen das layout unserer legacy-tools erwarten, alles zu sehen -- so kompilieren, zu einem 'bin' - Verzeichnis ist nicht gut genug, und ich fürchte, der Arbeitsbereich ist zu kommunalen meine Objekt-code-Dateien...
    • Ich hatte zunächst gedacht, dass das build-Verzeichnis der Zweck war zu Haus die generierten Dateien. Ich denke, das sind build-Artefakte? während die Verwaltung all dieser Sachen durch eine Infrastruktur ist wahrscheinlich der Weg zu gehen, meine unmittelbaren Bedürfnisse sind einfach zu dump-die Objekt-code-Dateien in ein Verzeichnis hat eine SMB-Freigabe, wir haben andere Dienstprogramme, die Dateien von dort aus und drücken Sie, um unsere runtime-Umgebungen (sorry, wenn ich war Irreführung durch Verwendung des Begriffs bereitstellen-für mich bereitstellen bedeutete einfach schieben Sie die Dateien auf dem SMB-Freigabe). nicht, dass zu klären?
    • Sie müssen prüfen, packen Sie Ihren code als JAR-oder war-Datei (abhängig von der Zielplattform). Dies ist die standard-Methode zum verteilen von Codes an die Benutzer, nicht-Verzeichnisse sind voll von class-Dateien. Sobald Ihr Aufbau unterstützt diesen Mechanismus können Sie nutzen eine binäre Datei-repository wie Nexus zu halten, diese release-Archiv versioniert. Die Benutzer können dann wählen Sie whicher version der app, die Sie ausführen müssen.
    • :- wir verwenden keine Java in meiner Firma 😉 wir sind mit proprietären interpretierte Sprachen. und meine aktuelle Aufgabe ist die Verbesserung der build-Prozess, die Ziele zu imitieren die 'shadow-folder" - Funktionalität, dass VSS zur Verfügung gestellt (wir haben vor kurzem die Migration zu Subversion). es ist alles baby-Schritte...ursprünglich schrieb ich einen post-commit-hook, die kicks off ein Ant-Skript, das funktioniert, aber irgendwie nervt das, weil die Entwickler zu warten. in einer anderen Frage, die ich nannte, Hudson/Jenkins und fing einfach an zu spielen (und ändern mein Ant-Skript entsprechend...
    • da Jenkins kann/wird, führen Sie die Kasse für mich, ich kann Sie pflücken eine Menge von crappy code/script. letztlich muss ich die Dateien verschieben, um in eine neue Hierarchie, und schieben Sie Sie dann auf eine SMB-Freigabe (für jetzt). sobald wir bequem mit Jenkins, dies zu tun, können wir die nächsten baby-step mit Kategorisierung build-Artefakte und so weiter. während ich arbeiten kann, um meine ursprüngliche Frage, es noch bleibt: gibt es nicht einen Weg, um herauszufinden, was den Jenkins-build-Ordner ist, aus einem Ant-Skript?
    • Ich aktualisiert meine Antwort
    • :- danke für das update, aber der Arbeitsbereich ist, wo die svn checkout geht, nicht dort, wo die build-Daten geht (jenkins erzeugt eine Handvoll drop von Dateien in das build-Verzeichnis, das sich in der <bauen.root>\<job.name>\<bauen.id> Ordner, wo bauen.root definiert ist, in der jenkins-Konfiguration. meines Wissens gibt es keine Umgebungsvariablen setup zu diesem Ort, obwohl es praktisch wäre, wenn es waren.
    • Die build-Daten-Pfad bestimmt werden kann, relativ zu der Arbeitsfläche Weg. Siehe meine überarbeitete Antwort. Wenn dies nicht funktioniert, würde ich vorschlagen, dass Sie der Versuchung widerstehen, über anpassen. Sie die gesamte Lösung ist seltsam und wunderbar (mit Betonung auf schön!).
    • :- das ist eine gute Lösung, die mir erlauben würde, zu vermeiden, dass Sie zu fest am Anfang Teile von dem Weg; ich werde es akzeptieren 😉 vielen Dank!

    InformationsquelleAutor Mark O'Connor
  2. 5

    Diesen Tagen (Jenkins v. 1.484) 'run' - Ziel von obige Antwort sollte wie folgt Aussehen:

    <target name="run">
    <echo message="Jenkins workspace: ${env.WORKSPACE}"/>
    <echo message="Job directory: ${env.WORKSPACE}/../../${env.JOB_NAME}"/>
    <echo message="Build data: ${env.WORKSPACE}/../../${env.JOB_NAME}/builds/${env.BUILD_ID}"/>
</target>
    InformationsquelleAutor Igor Kryltsov
Schreibe einen Kommentar