Das Setup wird verwendet, um Adobe AEM zu erstellen und bereitzustellen.
Der Master-Build-Job ruft das Git-Repository, Builds und Pakete ab, führt die Tests aus und feuert dann Downstream-Jobs, die die erstellten Pakete aus dem Upstream-Job verwenden sollen.
Das Problem besteht darin, dass der nachgelagerte Job mit der folgenden Fehlermeldung fehlschlägt:
%Vor%Es scheint mir, dass das CopyArtifacts-Plugin, ausgelöst durch den Downstream-Job, nach den Artefakten am falschen Ort sucht. Der richtige Ort wäre
%Vor%Aber dann klagt es über
%Vor%Der nachgelagerte Job kopiert Artefakte von einem anderen Projekt, und dann war der Build entweder "Upstream-Build, der diesen Job ausgelöst hat" oder "Vom Arbeitsbereich des letzten abgeschlossenen Builds kopieren". Und nichts funktioniert.
Irgendwelche Ideen?
Sie versuchen Artefakte zu verwenden, ohne sie vorher zu archivieren.
Sie versuchen, absolute Pfade zu verwenden, sollten aber relativ zu $WORKSPACE und / oder "Archivspeicherort" sein.
Sie verstehen das Konzept von "Artefakten" in Bezug auf Jenkins falsch.
Artefakte sind Dateien, die nach dem Build mithilfe der Archivieren der Artifacts Post-Build-Aktion
gespeichert werden. Wenn der Build ausgeführt wird, wird er in folgendem Format ausgeführt:
$WORKSPACE , das sich normalerweise in
$JENKINS_HOME/jobs/$JOB_NAME/workspace
befindet
Dort können Sie Ihre SCM-Checkout-Ordner, temporäre Build-Dateien, final erstellte Dateien, Binärdateien usw. haben.
Der Inhalt von $WORKSPACE ist volatil , Sie sollten sich außerhalb des Build-Zeitrahmens niemals darauf verlassen (und nach
$WORKSPACE könnte zwischen verschiedenen Master / Slave-Knoten unterschiedlich sein, er könnte jederzeit von admin oder durch SCM update / cleanup / checkout gelöscht werden.
Es ist auch wichtig zu verstehen, dass es nur eins $WORKSPACE für den gesamten Job gibt.
Aber jetzt achten Sie auf Ihre Build History , es gibt mehrere Einträge in dieser Liste, auf die Build-Nummer (#) und Datum-Zeitstempel verweisen.
Diese sind gespeichert unter:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID
mit $BUILD_ID als Datum-Zeitstempel des Builds, wie 2014-10-22_11-33-46
Das $WORKSPACE enthält die Informationen, die für aktuell oder zuletzt relevant sind (und das Problem ist: Sie können nie sicher sein, ob es "aktuell" oder "zuletzt" ist) bauen;
Der Ordner builds enthält eine Aufzeichnung aller bisherigen (beibehaltenen) Build-Ausführungen (das ist die Liste Build History auf der linken Seite), pro Build .
Standardmäßig enthält es nur das, was Jenkins selbst benötigt: build.xml-Kopie, changelog-Informationen, Konsolenprotokoll. Wenn Sie zur URL http://$JENKINS_URL/job/$JOB_NAME/[nn]/ gehen, wobei [nn] eine numerische Build- / Ausführungsnummer (#) ist, liest sie diese Informationen aus dem Ordner builds im Dateisystem.
Um Artefakte eines Builds zu erhalten (um zu verhindern, dass sie beim nächsten Build überschrieben werden, worktopspace ausgelöscht wird oder nur um auf ältere Builds zuzugreifen), müssen Sie Archive the Artifacts (mit demselben Post- Aktion mit demselben Titel erstellen). Wenn Sie die Artefakte archivieren, geben Sie an, welche Dateien in $WORKSPACE beibehalten werden sollen. Wenn Jenkins die Archivierung vornimmt, werden diese Dateien (die die Pfade [relativ zu $WORKSPACE ] beibehalten) in folgende Dateien eingefügt:
$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/ .
Auf diese Weise können Sie mehrere Artefakte für frühere Builds erhalten, nicht nur "Letzte / Letzte" von $WORKSPACE .
Der Vollständigkeit halber werde ich erwähnen, dass Jenkins "Permalinks", wie http://$JENKINS_URL/job/$JOB_NAME/lastSuccessfulBuild und /lastFailedBuild usw., tatsächlich Symlinks im Dateisystem zu einem der erhaltenen builds/$BUILD_ID Ordner sind.
Schließlich können Sie steuern, wie viele Build-Läufe und wie viele Artefakte beibehalten werden (kann separat konfiguriert werden), indem Sie das Kontrollkästchen "Alte Builds verwerfen" bei der Jobkonfiguration deaktivieren. Standardmäßig werden alle beibehalten, aber wenn Sie beginnen, Artefakte zu behalten, müssen Sie an die Kapazität des Festplattenspeichers denken.
Mit den obigen Informationen und der Betrachtung Ihrer Fehlermeldungen sollten Sie nun sehen, dass das Copy Artifacts -Plugin korrekt nach Artefakten im Abschnitt /archive/ eines Builds sucht.
Sie sollten außerdem beachten, dass Artefakte kopieren bei nicht die Option "aktueller Build" ausgewählt werden kann, wenn Sie auswählen, von welchem Build kopiert werden soll. Es hat Permalinks (wie "letzte erfolgreiche" oder "letzte Build") und spezifische Build-Nummern, die alle zu konservierten Builds unter $JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/
Auch "Upstream Build, das diesen Job ausgelöst hat" wird mit einem bestimmten $BUILD_ID verknüpft.
Die Konfiguration für Archivierungsartefakte ist relativ zu $WORKSPACE .
Die Konfiguration für Artefakte kopieren ist relativ zu "Archivspeicherort", dh $JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_ID/archive/ .
Da "Artefakte kopieren" relativ zu "Archivspeicherort" ist und "Archivspeicherort" relativ zu $WORKSPACE ist, können die relativen Pfade beider Konfigurationen für alle intensiven Zwecke gleich und relativ zu $WORKSPACE
$WORKSPACE haben, sollte es sein: PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip Upstream Build that triggered this job für die Auswahl Kopie-Artefakte .** oder leer, um alle archivierten Artefakte zu kopieren, oder PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip (entspricht dem Archivierungsabschnitt) Wenn Sie nicht archivieren möchten, können Sie $WORKSPACE direkt verwenden, mit Copy from workspace of latest completed build , Sie müssen jedoch sicherstellen, dass kein zweiter Upstream-Build ausgeführt werden kann, während der Downstream-Build ausgeführt wird, sonst Sie Risiko, eine partielle Datei von einem partiellen Build zu erhalten, da $WORKSPACE , wie zuvor erklärt, flüchtig ist.
$WORKSPACE , also: PROJECTNAME-*/**/*.jar,PROJECTNAME-*/**/*.zip Wenn Sie wirklich den gesamten ARBEITSBEREICH zwischen verschiedenen Jobs kopieren wollen, verwenden Sie entweder
Der Fehler kann so einfach sein: deaktivieren oder entfernen Artefakte komprimieren Plugin und Neustart Jenkins.
Dieser Workaround wurde aus einem langjährigen Fehlerbericht abgeleitet: "Copy Artifacts Plugin" sollte ArtifactManager unterstützen .
Die Lösung betrifft die Konfiguration des Builders.
Die Ursache liegt in der Konfiguration des nachgeordneten Jobs. Sobald "Kopie vom Arbeitsbereich des letzten abgeschlossenen Builds" für den Build ausgewählt wurde, der kopiert werden soll, wird der Pfad der zu kopierenden Artefakte auf den relativen Pfad gesetzt, z. B. projektname- / / .jar, Projektname- // .zip, dann ist der Build erfolgreich.
Außerdem muss in der übergeordneten Jobkonfiguration dem nachgeordneten Job erlaubt sein, CopyArtifact und Projekte so zu setzen, dass das Feld für Kopierartefakte den nachgelagerten Job angibt.
Edit: Jetzt sehe ich, dass du in der Zwischenzeit geantwortet hast. Große Antwort und im Grunde klären einige der Fragen, die ich hatte.
Das Unklare an Option 1 ist, dass die Archivierung der Dateien nach erfolgt, nachdem der übergeordnete Job abgeschlossen wurde.
%Vor%Nachdem ich den Ansatz für Option zwei geändert hatte, funktionierte es für mich, aber ich würde gerne auch die erste Option verstehen.
Tags und Links jenkins continuous-integration jenkins-plugins