Dieser Beitrag ist ein Blog-Beitrag von @ takahi-i, [Automatisches Hochladen von Java-Artefakten in das Nexus-Repository mit Walter- und Git-Hooks](https://walter-cd.net/2016/11/18/automatic-upload-aritfacts- Japanische Übersetzung von to-nexus-repository /).

TL;DR

Die interaktive Verarbeitung von Maven-Release-Plug-Ins ist fehleranfällig und schmerzhaft
Automatisieren Sie die Registrierung beim Nexus Repository (Maven Central) mithilfe von Walter.
Erweitert, sodass der Freigabeprozess automatisch ausgeführt wird, wenn Sie ein Upgrade mit GitHook durchführen (Dienste wie Jenkins und Tranvis sind nicht erforderlich).

Maven Release Plug-In

Der Autor dieses Artikels ist ein Entwicklungsmitglied von Walter, jedoch in Java mit dem Namen RedPen geschrieben. Er ist auch ein Entwicklungsmitglied der kalibrierten Werkzeuge. Die Artefakte dieses Tools (Jar- und War-Dateien) werden mit jeder Version zum Maven Central-Repository hinzugefügt. Zuvor haben wir das ** Release-Plugin ** von Maven verwendet, um Artefakte zum Maven Central-Repository hinzuzufügen.

Die Einrichtung zur Verwendung des Maven-Release-Plug-Ins ( pom.xml und elektronische Signatur) ist recht schwierig. Weitere Informationen finden Sie im Artikel hier. Sobald die Einstellungen abgeschlossen sind, können Sie die Artefakte jedoch bequem zum Maven Centaral-Repository hinzufügen, indem Sie zum Zeitpunkt der Veröffentlichung einfach den Befehl "mvn release" ausführen.

Aber in letzter Zeit hatte ich Probleme, das Release-Plugin für jedes Release auszuführen. In diesem Artikel wird daher erläutert, wie der Freigabeprozess automatisiert werden kann. Aber zuerst wollen wir über den Release-Prozess mit dem Release-Plug-In nachdenken.

Verarbeitung mit dem Release-Plug-In

Wenn Sie ein Release-Plug-In ausführen, erledigt es interaktiv viel Arbeit. Im Folgenden wird das Reelealse-Plug-In vorbereitet Es befindet sich in dem Zustand, in dem release: prepare ausgeführt wird.

➜  redpen git:(master) mvn release:prepare
[INFO] Scanning for projects...
...
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "redpen"? (cc.redpen:redpen) 1.7.5: :

Sie werden zunächst aufgefordert, die Version der Version einzugeben. Das Release-Plug-In zeigt die Release-Version der aktuellen Snapshot-Version (1.7.5 im obigen Beispiel). Wenn sich die präsentierte Version von der Version unterscheidet, die Sie freigeben möchten, geben Sie die Versionsnummer manuell ein.

Das Plug-In fragt dann nach einer zukünftigen Entwicklungsversion. Geben Sie es bei Bedarf manuell ein.

What is the new development version for "redpen"? (cc.redpen:redpen)
1.7.6-SNAPSHOT: :

Sobald dies erledigt ist, ändert das Plug-In eine neue Versionsnummer in git und verpflichtet sich zu git. Dann im aktuellen Zustand bauen.

Wenn der Build erfolgreich ist, werden Sie vom Plug-In aufgefordert, die Änderung der Versionsnummer in das Remote-Repository zu übertragen.

[INFO] Working directory: /Users/takahi-i/IdeaProjects/redpen
Username for 'https://github.com': Password for 'https://github.com':

Sie können sehen, dass der GitHub-Benutzername und das Passwort erforderlich sind. Selbst wenn "mvn release: prepare" erfolgreich ist, müssen Sie danach im nächsten "release: perform" -Befehl verschiedene Dinge interaktiv eingeben. Ich fürchte, ich habe es falsch geschrieben und immer wieder neu angefangen: ängstlich:

Release-Prozess automatisieren

Das Release-Plug-In, das wir im vorherigen Abschnitt gesehen haben, ist aufgrund der interaktiven Eingabearbeit umständlich zu verwenden.

Vorhergehender Fall

Als ich twitterte, ob es ein Beispiel gibt, das dieses Problem löst, die Folie "[Sie sind auch ein OSS-Entwickler! Verschiedene Tipps beim Hochladen Ihrer eigenen Bibliothek in das zentrale Maven-Repository](http: //www.slideshare) .net / nabedge / 20140405-maven-5java) ”wurde unterrichtet. Laut der Folie entfällt durch das Ersetzen der Befehle mvn version: set und mvn deploy die Interaktion.

Versuchen Sie es mit Walter

Die obige Folie verwendet den Jenkins-Server, um die erforderlichen Befehle auszuführen. Ich dachte jedoch, dass ein kleines Tool wie RedPen auf einem Server teuer sein würde. Als Motivation möchte ich irgendwie automatisieren, ohne den Server zu verwalten. Es kann auch mit einem externen CI-Dienst wie Wercker automatisiert werden, und der Vorgang kann dem Dienst überlassen werden, so dass es einfach ist.

Wenn der Bereitstellungsprozess mit diesen Diensten jedoch nicht gut funktioniert, sind die Protokollanalyse und die erneute Ausführung (erneutes Festschreiben und erneutes Drücken) etwas schwierig. Daher möchte ich sie nach Möglichkeit auf dem lokalen PC ausführen.

Also habe ich das Build-Pipeline-Tool Walter das tun lassen, was das Release-Plugin tut. Walter listet die Befehle auf, die Sie im YAML-Format ausführen möchten. Weitere Informationen finden Sie unter hier.

Das Folgende ist eine Flusseinstellung dessen, was das Release-Plug-In in Walter tut.

pipeline:
    - name: Set Version
      command: mvn versions:set -DnewVersion=$REDPEN_VERSION
    - name: Add Files to the Next Changes
      command: git add pom.xml; git add **/*.xml
    - name: Commit Version Changes
      command: git commit -m "Set version in pom.xml to $REDPEN_VERSION"
    - name: Delopy to Sonatype
      command: mvn clean deploy -DperformRelease --settings
~/.m2/settings.xml > redpen-distribution/target/walter.log
    - name: Create Release Tag
      command: git tag -a redpen-$REDPEN_VERSION -m "RedPen release
$REDPEN_VERSION"
    - name: Flush Next Release Version Number
      command: echo $REDPEN_VERSION | awk -F. -v OFS=. 'NF==1{print
++$NF}; NF>1{if(length($NF+1)>length($NF))$(NF-1)++;
$NF=sprintf("%0*d-SNAPSHOT", length($NF), ($NF+1)%(10^length($NF)));
print}'
    - name: Echo Next Version
      command: echo __OUT["Flush Next Release Version Number"]
    - name: Set next version
      command: mvn versions:set -DnewVersion=__OUT["Flush Next Release
Version Number"]
    - name: Git Add
      command: git add .
    - name: Commit New Snapshot version
      command: git commit -m "Update versions in pom.xml for next release"

Zunächst legt mvn version die von der Umgebungsvariablen angegebene Version fest. Dann registrieren Sie Ihre Änderungen bei git. Sie können jetzt Ihre Artefakte in Maven Central registrieren. Verwenden Sie in Delopy to Sonatype mvn clean deploy, um die Artefakte in Sonatype zu registrieren.

Geben Sie dann die Entwicklungsversion nach der Veröffentlichung an. Der Versionsname der Entwicklung hat normalerweise das Suffix "-SNAPSHOT". Berechnen Sie zunächst die nächste Versionsnummer ("Flush Next Release Versionsnummer") und geben Sie diese Version mit "mvn version: set" an. __OUT wird verwendet, um die in der angegebenen Stufe verwendete Standardausgabe wiederzuverwenden. Registrieren Sie diese Datei im RedPen-Repository unter dem Namen release.yml.

Jetzt müssen Sie nur noch den Befehl walter -c release.yml ausführen, um den Freigabeprozess abzuschließen (obwohl Sie bei Sonatype die Artefakte manuell schließen müssen).

Kombiniere mit Git Hook

Das Ausführen eines einzelnen Befehls auf die oben beschriebene Weise schließt nun den Freigabeprozess ab. Es gibt jedoch noch ein Problem. Mit RedPen können Sie die Version mit Befehlen und Servern überprüfen. Alle von RedPen verwendeten Versionen können geändert werden, indem eine Zeile in der Datei RedPen.java neu geschrieben wird. Das folgende Bild zeigt beispielsweise den RedPen-Server 1.7.7.

Ich habe jedoch vergessen, die Versionsnummer zu erhöhen und habe sie veröffentlicht: ängstlich: Ich habe darüber nachgedacht, dieses Problem mit GitHook zu lösen.

GitHook ist ein Mechanismus, der das angegebene Skript ausführt, wenn ein bestimmter git-Befehl ausgeführt wird. Dieses Mal werde ich versuchen, den Release-Befehl nur dann automatisch auszuführen, wenn die Commit-Nachricht zum Zeitpunkt des Git-Commits die Bump-Version lautet.

Ich habe die folgenden Dateien in ./git/hooks/post-commit abgelegt.

#!/bin/bash

LATEST_MESSAGE=`git log -1 --pretty=%B`

if echo $LATEST_MESSAGE | grep -q "^Bump version " ; then
   export REDPEN_VERSION=`echo $LATEST_MESSAGE | grep -o "[0-9.]\+"`
   echo "Extracted Version: " $REDPEN_VERSION
    ./walter -c release.yml
else
   echo "Not changed version"
fi

Wenn in dieser Datei die Festschreibungsnachricht "Bump vesrion" lautet (die Festschreibungsnachricht, die die RedPen-Version ändert, ist die Bump-Version), wird der Freigabeprozess ausgeführt. Aus diesem Grund ist es möglich, einen Unfall zu verhindern, bei dem der Freigabeprozess ausgeführt wird, obwohl die interne Version nicht aktualisiert wurde (sollte).

von jetzt an

RedPen schaltet den Beispielserver auf Heroku (http://redpen.herokuapp.com/) jedes Mal auf eine neuere Version um, wenn ein Commit in ein Remote-Repository übertragen wird. Ich verwende derzeit Jenkins, werde aber in Zukunft überlegen, ob der Beispielserver-Switching-Prozess lokal automatisiert werden kann.

[JAVA] Serverless (Walter + GitHook) registriert Ergebnisse automatisch im Nexus Repository (Maven Central).