Konfigurieren von GitLab CI zum Laden eines Java-Projekts in Maven Central

Dieser Artikel richtet sich an Java-Entwickler, die ihre Produkte mithilfe von GitLab schnell in den zentralen Sonatype- und / oder Maven-Repositorys veröffentlichen müssen. In diesem Artikel werde ich über das Einrichten von Gitlab-Runner, Gitlab-CI und Maven-Plugin sprechen, um dieses Problem zu lösen.

Voraussetzungen:

Sichere Speicherung von MVN- und GPG-Schlüsseln.
Sichere Ausführung öffentlicher CI-Aufgaben.
Laden Sie Artefakte (Release / Snapshot) in öffentliche Repositorys hoch.
Überprüfen Sie die Release-Versionen automatisch auf Veröffentlichung in Maven Central.
Eine allgemeine Lösung zum Hochladen von Artefakten in das Repository für mehrere Projekte.
Einfachheit und Benutzerfreundlichkeit.

Inhalt

allgemeine Informationen

Eine detaillierte Beschreibung des Mechanismus zum Veröffentlichen von Artefakten in Maven Central über den Sonatype OSS Repository Hosting Service wurde bereits in diesem Artikel von Googolplex beschrieben , daher werde ich an den richtigen Stellen auf diesen Artikel verweisen.
Wir registrieren uns vorab bei Sonatype JIRA und starten ein Ticket zum Öffnen des Repositorys (weitere Informationen finden Sie im Abschnitt Erstellen eines Tickets für Sonatype JIRA ). Nach dem Öffnen des Repositorys wird das JIRA-Anmelde- / Kennwortpaar (im Folgenden Sonatype-Konto) zum Hochladen von Artefakten in den Sonatype-Nexus verwendet.
Ferner wird der Prozess des Erzeugens eines GPG-Schlüssels sehr trocken beschrieben. Weitere Informationen finden Sie unter Konfigurieren von GnuPG zum Signieren von Artefakten .
Wenn Sie die Linux-Konsole zum Generieren des GPG-Schlüssels (gnupg / gnupg2) verwenden, müssen Sie rng-tools installieren, um Entropie zu generieren. Andernfalls kann die Schlüsselgenerierung sehr lange dauern.
Dienste zum Speichern öffentlicher GPG-Schlüssel

Konfigurieren eines Bereitstellungsprojekts in GitLab

Zunächst muss ein Projekt erstellt und konfiguriert werden, in dem die Pipeline für die Bereitstellung von Artefakten gespeichert wird. Ich habe mein Projekt einfach und unkompliziert genannt - bereitstellen
Nach dem Erstellen des Repositorys müssen Sie den Zugriff einschränken, um das Repository zu ändern.
Gehen Sie zu Projekt -> Einstellungen -> Repository -> Geschützte Zweige. Wir löschen alle Regeln und fügen die einzige Regel mit Platzhalter * hinzu, die das Recht hat, nur für Benutzer mit der Rolle "Verwalter" zu pushen und zusammenzuführen. Diese Regel gilt für alle Benutzer dieses Projekts sowie für die Gruppe, in der dieses Projekt enthalten ist.
Wenn es mehrere Betreuer gibt, besteht die beste Lösung darin, den Zugriff auf das Projekt im Prinzip zu beschränken.
Gehen Sie zu Projekt -> Einstellungen -> Allgemein -> Sichtbarkeit, Projektfunktionen, Berechtigungen und setzen Sie die Projektsichtbarkeit auf Privat .
Ich habe ein gemeinfreies Projekt, da ich meinen eigenen GitLab Runner verwende und nur ich Zugriff auf das Repository habe. Eigentlich liegt es nicht in meinem Interesse, private Informationen in öffentlichen Pipeline-Protokollen zu veröffentlichen.
Strengere Regeln zum Ändern des Repositorys
Gehen Sie zu Projekt -> Einstellungen -> Repository -> Push-Regeln und setzen Sie die Flags Committer-Einschränkung. Überprüfen Sie, ob der Autor ein GitLab-Benutzer ist. Ich empfehle außerdem, dass Sie die Signatur der Commits konfigurieren und das Flag "Nicht signierte Commits ablehnen" setzen.
Als Nächstes müssen Sie den Trigger so konfigurieren, dass Aufgaben ausgeführt werden
Gehen Sie zu Projekt -> Einstellungen -> CI / CD -> Pipeline-Trigger und erstellen Sie ein neues Trigger-Token
Dieses Token kann sofort zur allgemeinen Konfiguration von Variablen für eine Gruppe von Projekten hinzugefügt werden.
Gehen Sie zur Gruppe -> Einstellungen -> CI / CD -> Variablen und fügen Sie die Variable DEPLOY_TOKEN mit Trigger-Token in den Wert ein.

Gitlab-Läufer

In diesem Abschnitt wird die Konfiguration zum Starten von Aufgaben bei der Bereitstellung mit einem eigenen (spezifischen) und öffentlichen (freigegebenen) Runner beschrieben.

Spezifischer Läufer

Ich benutze meine eigenen Läufer, da es zuallererst bequem, schnell und billig ist.
Für Läufer empfehle ich Linux VDS mit 1 CPU, 2 GB RAM, 20 GB Festplatte. Der Ausgabepreis beträgt ~ 3000₽ pro Jahr.

Mein Läufer

Für den Läufer habe ich VDS 4 CPU, 4 GB RAM, 50 GB SSD genommen. Es kostete ~ 11.000 Rubel und bereute es nie.
Ich habe insgesamt 7 Autos. 5 auf Aruba und 2 auf Ihor.

Wir haben also einen Läufer. Jetzt werden wir es konfigurieren.
Wir gehen auf SSH zur Maschine und installieren Java, Git, Maven, Gnupg2.

Installieren Sie den Gitlab Runner

Erstellen Sie eine neue runner
```
 sudo groupadd runner 
```
Erstellen Sie ein Verzeichnis für den Maven-Cache und hängen Sie die Rechte der runner Gruppe an
Sie können diesen Punkt überspringen, wenn Sie nicht vorhaben, mehrere Läufer auf derselben Maschine zu fahren.
```
 mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache 
```

Erstellen Sie den gitlab-deployer und fügen Sie den runner der Gruppe hinzu

 useradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer

Fügen Sie der Datei /etc/ssh/sshd_config die folgende Zeile /etc/ssh/sshd_config
```
 AllowUsers root@* gitlab-deployer@127.0.0.1 
```
sshd
```
 systemctl restart sshd 
```
Wir legen das Kennwort für den gitlab-deployer (dies kann einfach sein, da die Einschränkung für localhost gilt).
```
 passwd gitlab-deployer 
```

Installieren Sie GitLab Runner (Linux x86-64)

 sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 sudo chmod +x /usr/local/bin/gitlab-runner ln -s /usr/local/bin/gitlab-runner /etc/alternatives/gitlab-runner ln -s /etc/alternatives/gitlab-runner /usr/bin/gitlab-runner

Gehen Sie zu gitlab.com -> Bereitstellungsprojekt -> Einstellungen -> CI / CD -> Läufer -> Bestimmte Läufer und kopieren Sie das Registrierungstoken

Bildschirm

Läufer registrieren

 gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml

Der Prozess

 Runtime platform arch=amd64 os=linux pid=17594 revision=3001a600 version=11.10.0 Running in system-mode. Please enter the gitlab-ci coordinator URL (eg https://gitlab.com/): https://gitlab.com/ Please enter the gitlab-ci token for this runner: REGISTRATION_TOKEN Please enter the gitlab-ci description for this runner: [ih1174328.vds.myihor.ru]: Deploy Runner Please enter the gitlab-ci tags for this runner (comma separated): deploy Registering runner... succeeded runner=ZvKdjJhx Please enter the executor: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell: shell Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Überprüfen Sie, ob der Läufer registriert ist. Gehen Sie zu gitlab.com -> Bereitstellungsprojekt -> Einstellungen -> CI / CD -> Läufer -> Bestimmte Läufer -> Für dieses Projekt aktivierte Läufer

Bildschirm

Fügen Sie einen separaten Dienst /etc/systemd/system/gitlab-deployer.service

 [Unit] Description=GitLab Deploy Runner After=syslog.target network.target ConditionFileIsExecutable=/usr/local/bin/gitlab-runner [Service] StartLimitInterval=5 StartLimitBurst=10 ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-deployer" "--config" "/etc/gitlab-runner/gitlab-deployer-config.toml" "--service" "gitlab-deployer" "--syslog" "--user" "gitlab-deployer" Restart=always RestartSec=120 [Install] WantedBy=multi-user.target

Wir starten den Service.

 systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service

Überprüfen Sie, ob der Läufer läuft.

Beispiel

GPG-Schlüsselgenerierung

Auf demselben Computer gehen wir unter dem Benutzer gitlab-deployer über ssh (dies ist wichtig, um einen GPG-Schlüssel zu generieren).
```
 ssh gitlab-deployer@127.0.0.1 
```
Wir generieren einen Schlüssel durch Beantwortung von Fragen. Ich habe meinen eigenen Namen und meine eigene Post verwendet.
Stellen Sie sicher, dass Sie das Kennwort für den Schlüssel angeben. Dieser Schlüssel signiert Artefakte.
```
 gpg --gen-key 
```

Überprüfen Sie

 gpg --list-keys -a /home/gitlab-deployer/.gnupg/pubring.gpg ---------------------------------------- pub 4096R/00000000 2019-04-19 uid Petruha Petrov <pp@example.com> sub 4096R/11111111 2019-04-19

Hochladen unseres öffentlichen Schlüssels auf den Schlüsselserver

 gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net

Maven Setup

Wir gehen unter den Benutzer gitlab-deployer
```
 su gitlab-deployer 
```
Erstellen Sie ein Maven- Repository und verknüpfen Sie es mit dem Cache (machen Sie keinen Fehler)
Sie können diesen Punkt überspringen, wenn Sie nicht vorhaben, mehrere Läufer auf derselben Maschine zu starten.
```
 mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository 
```

Erstellen Sie einen Hauptschlüssel

 mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}

Erstellen Sie die Datei ~ / .m2 / settings-security.xml

 <settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity>

Wir verschlüsseln das Passwort für das Sonatype-Konto

 mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}

Erstellen Sie die Datei ~ / .m2 / settings.xml

 <settings> <profiles> <profile> <id>env</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>sonatype</id> <username>SONATYPE_USERNAME</username> <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password> </server> </servers> </settings>

wo
GPG_SECRET_KEY_PASSPHRASE - Passwort vom GPG-Schlüssel
SONATYPE_USERNAME - Sonatype-Kontoanmeldung

Damit ist das Runner-Setup abgeschlossen. Sie können zum Abschnitt GitLab CI gehen

Geteilter Läufer

GPG-Schlüsselgenerierung

Zunächst müssen Sie einen GPG-Schlüssel erstellen. Installieren Sie dazu gnupg.
```
 yum install -y gnupg 
```
Wir generieren einen Schlüssel durch Beantwortung von Fragen. Ich habe meinen eigenen Namen und meine eigene Post verwendet. Stellen Sie sicher, dass Sie das Kennwort für den Schlüssel angeben.
```
 gpg --gen-key 
```

Wir zeigen Informationen auf dem Schlüssel an

 gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [expires: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp <temp@temp.temp> sub rsa3072 2019-04-24 [E] [expires: none]

Hochladen unseres öffentlichen Schlüssels auf den Schlüsselserver

 gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sending key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 to hkp server keys.gnupg.net

Holen Sie sich den privaten Schlüssel

 gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK-----

Gehen Sie zu den Projekteinstellungen -> Einstellungen -> CI / CD -> Variablen und speichern Sie den privaten Schlüssel in der Variablen GPG_SECRET_KEY

Maven Setup

Erstellen Sie einen Hauptschlüssel

 mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}

Gehen Sie zu den Projekteinstellungen -> Einstellungen -> CI / CD -> Variablen und speichern Sie die folgenden Zeilen in der Variablen SETTINGS_SECURITY_XML :
```
 <settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> 
```

Wir verschlüsseln das Passwort für das Sonatype-Konto

 mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}

Gehen Sie zu den Projekteinstellungen -> Einstellungen -> CI / CD -> Variablen und speichern Sie die folgenden Zeilen in der Variablen SETTINGS_XML :

 <settings> <profiles> <profile> <id>env</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>sonatype</id> <username>sonatype_username</username> <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password> </server> </servers> </settings>

wo
GPG_SECRET_KEY_PASSPHRASE - Passwort vom GPG-Schlüssel
SONATYPE_USERNAME - Sonatype-Kontoanmeldung

Stellen Sie das Docker-Image bereit

Erstellen Sie eine Docker-Datei, die einfach genug ist, um Aufgaben bei der Bereitstellung mit der richtigen Java-Version auszuführen. Unten ist ein Beispiel für alpine.

 FROM java:8u111-jdk-alpine RUN apk add gnupg maven git --update-cache \ --repository http://dl-4.alpinelinux.org/alpine/edge/community/ --allow-untrusted && \ mkdir ~/.m2/

Wir sammeln den Container für Ihr Projekt

 docker build -t registry.gitlab.com/group/deploy .

Authentifizieren Sie den Container und laden Sie ihn in die Registrierung.

 docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy

Gitlab ci

Projekt bereitstellen

Fügen Sie die Datei .gitlab-ci.yml zum Stammverzeichnis des Bereitstellungsprojekts hinzu
Das Skript enthält zwei sich gegenseitig ausschließende Aufgaben bei der Bereitstellung. Spezifischer Läufer bzw. gemeinsamer Läufer.

.gitlab-ci.yml

 stages: - deploy Specific Runner: extends: .java_deploy_template #      shell- tags: - deploy Shared Runner: extends: .java_deploy_template #      docker- tags: - docker #    GitLab Runner -> Shared Runner -> Docker image: registry.gitlab.com/group/deploy-project:latest before_script: #  GPG  - printf "${GPG_SECRET_KEY}" | gpg --batch --import #  maven  - printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml - printf "${SETTINGS_XML}" > ~/.m2/settings.xml .java_deploy_template: stage: deploy #    ,    DEPLOY   java only: variables: - $DEPLOY == "java" variables: #     GIT_STRATEGY: none script: #        - git config --global credential.helper store #     gitlab-ci-token #       gitlab.com     - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials #     - rm -rf .* * #   ,    Sonatype Nexus - git clone ${DEPLOY_CI_REPOSITORY_URL} . #     - git checkout ${DEPLOY_CI_COMMIT_SHA} -f #    pom.xml   autoReleaseAfterClose  . #          maven central - > for pom in $(find . -name pom.xml); do if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then echo "File $pom contains prohibited setting: <autoReleaseAfterClose>"; exit 1; fi; done #   DEPLOY_CI_COMMIT_TAG ,    SNAPSHOT- - > if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then mvn versions:set -DnewVersion=${DEPLOY_CI_COMMIT_TAG} else VERSION=$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec) if [[ "${VERSION}" == *-SNAPSHOT ]]; then mvn versions:set -DnewVersion=${VERSION} else mvn versions:set -DnewVersion=${VERSION}-SNAPSHOT fi fi #        - mvn clean deploy -DskipTests=true

Java-Projekt

In Java-Projekten, die in öffentliche Repositorys hochgeladen werden sollen, müssen Sie zwei Schritte hinzufügen, um die Versionen Release und Snapshot herunterzuladen.

.gitlab-ci.yml

 stages: - build - test - verify - deploy <...> Release: extends: .trigger_deploy #    o . only: - tags Snapshot: extends: .trigger_deploy #     SNAPSHOT   when: manual #   ,   . except: - tags .trigger_deploy: stage: deploy variables: #     GIT_STRATEGY: none #    deploy- URL: "https://gitlab.com/api/v4/projects/<deploy project ID>/trigger/pipeline" #  deploy- POST_DATA: "\ token=${DEPLOY_TOKEN}&\ ref=master&\ variables[DEPLOY]=${DEPLOY}&\ variables[DEPLOY_CI_REPOSITORY_URL]=${CI_REPOSITORY_URL}&\ variables[DEPLOY_CI_PROJECT_NAME]=${CI_PROJECT_NAME}&\ variables[DEPLOY_CI_COMMIT_SHA]=${CI_COMMIT_SHA}&\ variables[DEPLOY_CI_COMMIT_TAG]=${CI_COMMIT_TAG} " script: #   cURL,     --fail --show-error #     ,  HTTP  400   - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}

Bei dieser Lösung ging ich etwas weiter und entschied mich, eine CI-Vorlage für Java-Projekte zu verwenden.

Ausführlicher

Ich habe ein separates gitlab-ci- Projekt erstellt, in dem ich eine CI-Vorlage für common.yml- Java-Projekte platziert habe.

common.yml

 stages: - build - test - verify - deploy variables: SONAR_ARGS: "\ -Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA} \ -Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME} \ " .build_java_project: stage: build tags: - touchbit-shell variables: SKIP_TEST: "false" script: - mvn clean - mvn package -DskipTests=${SKIP_TEST} artifacts: when: always expire_in: 30 day paths: - "*/target/reports" .build_sphinx_doc: stage: build tags: - touchbit-shell variables: DOCKERFILE: .indirect/docs/Dockerfile script: - docker build --no-cache -t ${CI_PROJECT_NAME}/doc -f ${DOCKERFILE} . .junit_module_test_run: stage: test tags: - touchbit-shell variables: MODULE: "" script: - cd ${MODULE} - mvn test artifacts: when: always expire_in: 30 day paths: - "*/target/reports" .junit_test_run: stage: test tags: - touchbit-shell script: - mvn test artifacts: when: always expire_in: 30 day paths: - "*/target/reports" .sonar_review: stage: verify tags: - touchbit-shell dependencies: [] script: - > if [ "$CI_BUILD_REF_NAME" == "master" ]; then mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS else mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS -Dsonar.analysis.mode=preview fi .trigger_deploy: stage: deploy tags: - touchbit-shell variables: URL: "https://gitlab.com/api/v4/projects/10345765/trigger/pipeline" POST_DATA: "\ token=${DEPLOY_TOKEN}&\ ref=master&\ variables[DEPLOY]=${DEPLOY}&\ variables[DEPLOY_CI_REPOSITORY_URL]=${CI_REPOSITORY_URL}&\ variables[DEPLOY_CI_PROJECT_NAME]=${CI_PROJECT_NAME}&\ variables[DEPLOY_CI_COMMIT_SHA]=${CI_COMMIT_SHA}&\ variables[DEPLOY_CI_COMMIT_TAG]=${CI_COMMIT_TAG} " script: - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA} .trigger_release_deploy: extends: .trigger_deploy only: - tags .trigger_snapshot_deploy: extends: .trigger_deploy when: manual except: - tags

In Java-Projekten selbst sieht .gitlab-ci.yml daher sehr kompakt und nicht ausführlich aus

.gitlab-ci.yml

 include: https://gitlab.com/TouchBIT/gitlab-ci/raw/master/common.yml Shields4J: extends: .build_java_project Sphinx doc: extends: .build_sphinx_doc variables: DOCKERFILE: .docs/Dockerfile Sonar review: extends: .sonar_review dependencies: - Shields4J Release: extends: .trigger_release_deploy Snapshot: extends: .trigger_snapshot_deploy

Pom.xml Konfiguration

Dieses Thema wird von Googolplex unter Konfigurieren des Maven für das automatische Signieren und Hochladen von Artefakten in Snapshot- und Staging-Repositorys ausführlich beschrieben. Daher werde ich einige der Nuancen der Verwendung von Plugins beschreiben. Ich werde auch beschreiben, wie einfach und natürlich Sie das nexus-staging-maven-plugin wenn Sie org.sonatype.oss: oss-parent nicht als übergeordnetes Element für Ihr Projekt verwenden möchten oder können.

Maven-Install-Plugin

Installiert Module im lokalen Repository.
Sehr nützlich für die lokale Überprüfung von Lösungen in anderen Projekten sowie für eine Prüfsumme.

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-install-plugin</artifactId> <executions> <execution> <id>install-project</id> <!--          --> <phase>install</phase> <!--       --> <configuration> <file>target/${project.artifactId}-${project.version}.jar</file> ```target/${project.artifactId}-${project.version}-sources.jar</sources> <pomFile>dependency-reduced-pom.xml</pomFile> <!--     --> <updateReleaseInfo>true</updateReleaseInfo> <!--      --> <createChecksum>true</createChecksum> </configuration> </execution> </executions> </plugin>

Maven-Javadoc-Plugin

Javadoc für das Projekt generieren.

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <goals> <goal>jar</goal> </goals> <!--  javadoc       --> <phase>prepare-package</phase> <configuration> <!--      --> <failOnError>true</failOnError> <failOnWarnings>true</failOnWarnings> <!--      target  --> <detectOfflineLinks>false</detectOfflineLinks> </configuration> </execution> </executions> </plugin>

Wenn Sie ein Modul haben, das kein Java enthält (z. B. nur Ressourcen)
Oder Sie möchten im Prinzip maven-jar-plugin generieren, dann maven-jar-plugin

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <id>empty-javadoc-jar</id> <phase>generate-resources</phase> <goals> <goal>jar</goal> </goals> <configuration> <classifier>javadoc</classifier> <classesDirectory>${basedir}/javadoc</classesDirectory> </configuration> </execution> </executions> </plugin>

Maven-GPG-Plugin

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <executions> <execution> <id>sign-artifacts</id> <!--   ,   GPG  --> <!--      deploy --> <phase>deploy</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin>

Nexus-Staging-Maven-Plugin

Konfiguration:

 <project> <!-- ... --> <build> <plugins> <!-- ... --> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> </plugin> </plugins> <pluginManagement> <plugins> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <serverId>sonatype</serverId> <nexusUrl>https://oss.sonatype.org/</nexusUrl> <!--  ,     release --> <!--    snapshot  --> <updateReleaseInfo>true</updateReleaseInfo> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <configuration> <!--   --> <skip>true</skip> </configuration> </plugin> </plugins> </pluginManagement> </build> <distributionManagement> <snapshotRepository> <id>sonatype</id> <name>Nexus Snapshot Repository</name> <url>https://oss.sonatype.org/content/repositories/snapshots/</url> </snapshotRepository> <repository> <id>sonatype</id> <name>Nexus Release Repository</name> <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url> </repository> </distributionManagement> </project>

Wenn Sie ein Projekt mit mehreren Modulen haben und kein bestimmtes Modul in das Repository laden müssen, fügen Sie der skipNexusStagingDeployMojo pom.xml dieses Moduls das nexus-staging-maven-plugin mit dem Flag skipNexusStagingDeployMojo

 <build> <plugins> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <configuration> <skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo> </configuration> </plugin> </plugins> </build>

Nach dem Herunterladen sind Snapshot- / Release-Versionen im Staging-Repository verfügbar .

 <repositories> <repository> <id>SonatypeNexus</id> <url>https://oss.sonatype.org/content/groups/staging/</url> <!--     snapshot/release   --> </repository> </repositories>

Weitere Vorteile

Eine sehr umfangreiche Liste von Zielen für die Arbeit mit dem Nexus-Repository ( mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin ).
Überprüfen Sie die Freigabe automatisch auf Download-Fähigkeit in Maven Central

Ergebnis

Veröffentlichen Sie die SNAPSHOT-Version

Beim Erstellen eines Projekts besteht die Möglichkeit, eine Aufgabe manuell herunterzuladen, um die SNAPSHOT-Version im Nexus herunterzuladen

Wenn diese Aufgabe gestartet wird, wird die entsprechende Aufgabe im Bereitstellungsprojekt ausgelöst ( Beispiel ).

Beschnittenes Protokoll

 Running with gitlab-runner 11.10.0 (3001a600) on Deploy runner JSKWyxUw Using Shell executor... Running on ih1174328.vds.myihor.ru... Skipping Git repository setup Skipping Git checkout Skipping Git submodules setup $ rm -rf .* * $ git config --global credential.helper store $ echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials $ git clone ${DEPLOY_CI_REPOSITORY_URL} . Cloning into 'shields4j'... $ git checkout ${DEPLOY_CI_COMMIT_SHA} Note: checking out '850f86aa317194395c5387790da1350e437125a7'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 850f86a... skip deploy test-core $ for pom in $(find . -name pom.xml); do # collapsed multi-line command $ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # collapsed multi-line command [INFO] Scanning for projects... [INFO] Inspecting build with total of 4 modules... [INFO] Installing Nexus Staging features: [INFO] ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] Shields4J [pom] [INFO] test-core [jar] [INFO] Shields4J client [jar] [INFO] TestNG listener [jar] [INFO] [INFO] --------------< org.touchbit.shields4j:shields4j-parent >--------------- [INFO] Building Shields4J 1.0.0 [1/4] [INFO] --------------------------------[ pom ]--------------------------------- [INFO] [INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent --- [INFO] Searching for local aggregator root... [INFO] Local aggregation root: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j [INFO] Processing change of org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT [INFO] Processing org.touchbit.shields4j:shields4j-parent [INFO] Updating project org.touchbit.shields4j:shields4j-parent [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] [INFO] Processing org.touchbit.shields4j:client [INFO] Updating parent org.touchbit.shields4j:shields4j-parent [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] Updating dependency org.touchbit.shields4j:test-core [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] [INFO] Processing org.touchbit.shields4j:test-core [INFO] Updating parent org.touchbit.shields4j:shields4j-parent [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] [INFO] Processing org.touchbit.shields4j:testng [INFO] Updating parent org.touchbit.shields4j:shields4j-parent [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] Updating dependency org.touchbit.shields4j:client [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] Updating dependency org.touchbit.shields4j:test-core [INFO] from version 1.0.0 to 1.0.0-SNAPSHOT [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Shields4J 1.0.0 .................................... SUCCESS [ 0.992 s] [INFO] test-core .......................................... SKIPPED [INFO] Shields4J client ................................... SKIPPED [INFO] TestNG listener 1.0.0 .............................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.483 s [INFO] Finished at: 2019-04-21T02:40:42+03:00 [INFO] ------------------------------------------------------------------------ $ mvn clean deploy -DskipTests=${SKIP_TESTS} [INFO] Scanning for projects... [INFO] Inspecting build with total of 4 modules... [INFO] Installing Nexus Staging features: [INFO] ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] Shields4J [pom] [INFO] test-core [jar] [INFO] Shields4J client [jar] [INFO] TestNG listener [jar] [INFO] [INFO] --------------< org.touchbit.shields4j:shields4j-parent >--------------- [INFO] Building Shields4J 1.0.0-SNAPSHOT [1/4] [INFO] --------------------------------[ pom ]--------------------------------- ... DELETED ... [INFO] * Bulk deploy of locally gathered snapshot artifacts finished. [INFO] Remote deploy finished with success. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUCCESS [ 2.375 s] [INFO] test-core .......................................... SUCCESS [ 3.929 s] [INFO] Shields4J client ................................... SUCCESS [ 3.815 s] [INFO] TestNG listener 1.0.0-SNAPSHOT ..................... SUCCESS [ 36.134 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 47.629 s [INFO] Finished at: 2019-04-21T02:41:32+03:00 [INFO] ------------------------------------------------------------------------

Infolgedessen wird Version 1.0.0-SNAPSHOT in nexus geladen.

Alle Snapshot-Versionen können aus dem Repository unter oss.sonatype.org unter Ihrem Konto gelöscht werden.

Release-Version veröffentlichen

Wenn das Tag installiert ist, wird automatisch die entsprechende Aufgabe im Bereitstellungsprojekt ausgelöst, um die Release-Version in nexus herunterzuladen ( Beispiel ).

Das Beste daran ist, dass eine enge Freigabe im Nexus automatisch ausgelöst wird.

 [INFO] Performing remote staging... [INFO] [INFO] * Remote staging into staging profile ID "9043b43f77dcc9" [INFO] * Created staging repository with ID "orgtouchbit-1037". [INFO] * Staging repository at https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037 [INFO] * Uploading locally staged artifacts to profile org.touchbit [INFO] * Upload of locally staged artifacts finished. [INFO] * Closing staging repository with ID "orgtouchbit-1037". Waiting for operation to complete... ......... [INFO] Remote staged 1 repositories, finished with success. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Shields4J 1.0.0 .................................... SUCCESS [ 9.603 s] [INFO] test-core .......................................... SUCCESS [ 3.419 s] [INFO] Shields4J client ................................... SUCCESS [ 9.793 s] [INFO] TestNG listener 1.0.0 .............................. SUCCESS [01:23 min] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 01:47 min [INFO] Finished at: 2019-04-21T04:05:46+03:00 [INFO] ------------------------------------------------------------------------

Und wenn etwas schief gelaufen ist, wird die Aufgabe sicherlich scheitern

 [INFO] Performing remote staging... [INFO] [INFO] * Remote staging into staging profile ID "9043b43f77dcc9" [INFO] * Created staging repository with ID "orgtouchbit-1038". [INFO] * Staging repository at https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038 [INFO] * Uploading locally staged artifacts to profile org.touchbit [INFO] * Upload of locally staged artifacts finished. [INFO] * Closing staging repository with ID "orgtouchbit-1038". Waiting for operation to complete... ....... [ERROR] Rule failure while trying to close staging repository with ID "orgtouchbit-1039". [ERROR] [ERROR] Nexus Staging Rules Failure Report [ERROR] ================================== [ERROR] [ERROR] Repository "orgtouchbit-1039" failures [ERROR] Rule "signature-staging" failures [ERROR] * No public key: Key with id: (1f42b618d1cbe1b5) was not able to be located on &lt;a href=http://keys.gnupg.net:11371/&gt;http://keys.gnupg.net:11371/&lt;/a&gt;. Upload your public key and try the operation again. ... [ERROR] Cleaning up local stage directory after a Rule failure during close of staging repositories: [orgtouchbit-1039] [ERROR] * Deleting context 9043b43f77dcc9.properties [ERROR] Cleaning up remote stage repositories after a Rule failure during close of staging repositories: [orgtouchbit-1039] [ERROR] * Dropping failed staging repository with ID "orgtouchbit-1039" (Rule failure during close of staging repositories: [orgtouchbit-1039]). [ERROR] Remote staging finished with a failure: Staging rules failure! [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Shields4J 1.0.0 .................................... SUCCESS [ 4.073 s] [INFO] test-core .......................................... SUCCESS [ 2.788 s] [INFO] Shields4J client ................................... SUCCESS [ 3.962 s] [INFO] TestNG listener 1.0.0 .............................. FAILURE [01:07 min] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------

. .

,

, maven .
robots.txt, .

Fazit

deploy- CI .
Deploy- Owner Maintainer.
Specific Runner "" deploy .
snapshot/release .
release maven central.
"" maven central.
snapshot " ".
snapshot/release .
// java .

GitLab CI . CI " " , . GitLab . . ( :) ).

.

, GitLab CI ( docker-compose), shell .

Source: https://habr.com/ru/post/de449664/

All Articles