Configuration de GitLab CI pour charger un projet Java dans Maven Central

Cet article est destiné aux développeurs java qui ont besoin de publier rapidement leurs produits dans les référentiels centraux sonatype et / ou maven à l'aide de GitLab. Dans cet article, je parlerai de la configuration de gitlab-runner, gitlab-ci et maven-plugin pour résoudre ce problème.

Prérequis:

• Stockage sécurisé des clés mvn et GPG.
• Exécution sûre des tâches CI publiques.
• Téléchargez des artefacts (version / instantané) dans des référentiels publics.
• Vérifier automatiquement les versions des versions pour publication dans maven central.
• Une solution générale pour télécharger des artefacts dans le référentiel pour plusieurs projets.
• Simplicité et convivialité.

Table des matières

• Informations générales
• Configuration du projet de déploiement dans GitLab
• Gitlab runner
  
  • Coureur spécifique
    
    • Installer gitlab runner
    • Génération de clés GPG
    • Configuration de Maven
  • Coureur partagé
    
    • Génération de clés GPG
    • Configuration de Maven
    • Déployer l'image Docker
• Gitlab ci
  
  • Déployer le projet
  • Projet Java
• Configuration de Pom.xml
  
  • maven-install-plugin
  • plugin maven-javadoc
  • plugin maven-gpg
  • nexus-staging-maven-plugin
• Résultat
  
  • Publier la version de l'instantané
  • Publier la version finale
• Conclusion

Informations générales

• Une description détaillée du mécanisme de publication des artefacts sur Maven Central via le service d'hébergement de référentiel Sonatype OSS a déjà été décrite dans cet article par Googolplex , je vais donc me référer à cet article aux bons endroits.
• Nous nous pré-enregistrons auprès de Sonatype JIRA et commençons un ticket pour ouvrir le référentiel (pour plus de détails, lisez la section Création d'un ticket pour Sonatype JIRA ). Après avoir ouvert le référentiel, la paire identifiant / mot de passe JIRA (ci-après compte Sonatype) sera utilisée pour télécharger des artefacts sur Sonatype nexus.
• De plus, le processus de génération d'une clé GPG est décrit très sèchement. Voir Configuration de GnuPG pour la signature d'artefacts pour plus d'informations.
• Si vous utilisez la console Linux pour générer la clé GPG (gnupg / gnupg2), vous devez installer rng-tools pour générer l'entropie. Sinon, la génération de clés peut prendre très longtemps.
• Services de stockage de clés GPG publiques
  
  • http://keys.gnupg.net
  • http://pool.sks-keyservers.net
  • http://keyserver.ubuntu.com

Vers le contenu

Configuration d'un projet de déploiement dans GitLab

• Tout d'abord, il est nécessaire de créer et de configurer un projet dans lequel le pipeline sera stocké pour le déploiement des artefacts. J'ai appelé mon projet simple et direct - déployer
• Après avoir créé le référentiel, vous devez restreindre l'accès pour modifier le référentiel.
  Accédez au projet -> Paramètres -> Référentiel -> Branches protégées. Nous supprimons toutes les règles et ajoutons la seule règle avec Wildcard * avec le droit de pousser et de fusionner uniquement pour les utilisateurs avec le rôle Maintainers. Cette règle fonctionnera pour tous les utilisateurs de ce projet, ainsi que pour le groupe dont ce projet est membre.
  
• S'il y a plusieurs mainteneurs, la meilleure solution serait de limiter en principe l'accès au projet.
  Accédez au projet -> Paramètres -> Général -> Visibilité, fonctionnalités du projet, autorisations et définissez la visibilité du projet sur Privé .
  J'ai un projet dans le domaine public, car j'utilise mon propre GitLab Runner et seulement j'ai accès pour changer le référentiel. Eh bien, en fait, ce n'est pas dans mon intérêt de diffuser des informations privées dans les journaux de pipeline publics.
• Des règles plus strictes pour changer le référentiel
  Allez dans le projet -> Paramètres -> Référentiel -> Règles Push et définissez la restriction Committer drapeaux, Vérifiez si l'auteur est un utilisateur GitLab. Je vous recommande également de configurer la signature des validations et de définir l'indicateur Rejeter les validations non signées.
• Ensuite, vous devez configurer le déclencheur pour exécuter des tâches
  Accédez au projet -> Paramètres -> CI / CD -> Déclencheurs de pipeline et créez un nouveau jeton de déclenchement
  Ce jeton peut être immédiatement ajouté à la configuration générale des variables pour un groupe de projets.
  Allez dans le groupe -> Paramètres -> CI / CD -> Variables et ajoutez la variable DEPLOY_TOKEN avec trigger-token dans la valeur.

Vers le contenu

Gitlab runner

Cette section décrit la configuration pour lancer des tâches lors du déploiement à l'aide de son propre runner (spécifique) et public (partagé).

Coureur spécifique

J'utilise mes propres coureurs, tout d'abord c'est pratique, rapide, pas cher.
Pour les coureurs, je recommande Linux VDS avec 1 CPU, 2 Go de RAM, 20 Go de disque dur. Le prix d'émission est de ~ 3000₽ par an.

Nous avons donc un coureur. Nous allons maintenant le configurer.
Nous allons à la machine sur SSH et installons java, git, maven, gnupg2.

Vers le contenu

Installer gitlab runner

• Créer un nouveau groupe de runner
  
  

   sudo groupadd runner 

• Créez un répertoire pour le cache maven et attachez les droits du groupe de runner
  Vous pouvez ignorer cet élément si vous ne prévoyez pas d'exécuter plusieurs coureurs sur la même machine.
  
  

   mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache 

• Créez l'utilisateur gitlab-deployer et ajoutez le runner au groupe
  
  

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

• Ajoutez la ligne suivante au fichier /etc/ssh/sshd_config
  
  

   AllowUsers root@* gitlab-deployer@127.0.0.1 

• Redémarrez sshd
  
  

   systemctl restart sshd 

• Nous définissons le mot de passe de l'utilisateur gitlab-deployer (cela peut être simple, car la restriction pour localhost s'applique)
  
  

   passwd gitlab-deployer 

• Installer 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 

• Accédez à gitlab.com -> deploy-project -> Settings -> CI / CD -> Runners -> Specific Runners and copy registration token

• Inscrire le coureur
  
  

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

 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! 

• Vérifiez que le coureur est enregistré. Allez sur gitlab.com -> deploy-project -> Settings -> CI / CD -> Runners -> Specific Runners -> Runners enabled for this project

• Ajouter un service distinct /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 

• Nous commençons le service.
  
  

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

• Vérifiez que le coureur est en cours d'exécution.

Vers le contenu

Génération de clés GPG

• À partir de la même machine, nous gitlab-deployer ssh sous l'utilisateur gitlab-deployer (c'est important pour générer une clé GPG)
  
  

  
  

   ssh gitlab-deployer@127.0.0.1 

  
  

• Nous générons une clé en répondant aux questions. J'ai utilisé mon propre nom et mon courrier.
  Assurez-vous de spécifier le mot de passe de la clé. Cette clé signera des artefacts.
  
  

  
  

   gpg --gen-key 

  
  

• Vérifier
  
  

  
  

   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 

  
  

• Téléchargement de notre clé publique sur le serveur de clés
  
  

  
  

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

  
  

Vers le contenu

Configuration de Maven

• Nous passons sous l'utilisateur gitlab-deployer
  
  

   su gitlab-deployer 

• Créez un référentiel maven et un lien vers le cache (ne vous y trompez pas)
  Vous pouvez ignorer cet élément si vous ne prévoyez pas de lancer plusieurs coureurs sur la même machine.
  
  

   mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository 

• Créer une clé principale
  
  

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

• Créez le fichier ~ / .m2 / settings-security.xml
  
  

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

• Nous cryptons le mot de passe du compte Sonatype
  
  

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

• Créez le fichier ~ / .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> 

où
GPG_SECRET_KEY_PASSPHRASE - mot de passe de la clé GPG
SONATYPE_USERNAME - connexion au compte sonatype

Ceci termine la configuration du runner, vous pouvez aller dans la section GitLab CI

Vers le contenu

Coureur partagé

Génération de clés GPG

• Tout d'abord, vous devez créer une clé GPG. Pour ce faire, installez gnupg.
  
  

  
  

   yum install -y gnupg 

  
  

• Nous générons une clé en répondant aux questions. J'ai utilisé mon propre nom et mon courrier. Assurez-vous de spécifier le mot de passe de la clé.
  
  

  
  

   gpg --gen-key 

  
  

• Nous affichons des informations sur la clé
  
  

  
  

   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] 

  
  

• Téléchargement de notre clé publique sur le serveur de clés
  
  

  
  

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

  
  

• Obtenez la clé privée
  
  

  
  

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

  
  

• Accédez aux paramètres du projet -> Paramètres -> CI / CD -> Variables et enregistrez la clé privée dans la variable GPG_SECRET_KEY
  

  
  

Vers le contenu

Configuration de Maven

• Créer une clé principale
  
  

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

• Accédez aux paramètres du projet -> Paramètres -> CI / CD -> Variables et enregistrez les lignes suivantes dans la variable SETTINGS_SECURITY_XML :
  

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

• Nous cryptons le mot de passe du compte Sonatype
  

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

• Accédez aux paramètres du projet -> Paramètres -> CI / CD -> Variables et enregistrez les lignes suivantes dans la variable 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> 

où
GPG_SECRET_KEY_PASSPHRASE - mot de passe de la clé GPG
SONATYPE_USERNAME - connexion au compte sonatype

Vers le contenu

Déployer l'image Docker

• Créez un Dockerfile assez simple pour exécuter des tâches lors du déploiement avec la bonne version de Java. Voici un exemple pour alpin.

  
  

   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/ 

  
  

• Nous récupérons le conteneur pour votre projet

  
  

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

  
  

• Authentifiez et chargez le conteneur dans le registre.

  
  

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

  
  

Vers le contenu

Gitlab ci

Déployer le projet

Ajoutez le fichier .gitlab-ci.yml à la racine du projet de déploiement
Le script présente deux tâches mutuellement exclusives lors du déploiement. Runner spécifique ou Runner partagé respectivement.

 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 

Vers le contenu

Projet Java

Dans les projets java censés être téléchargés dans des référentiels publics, vous devez ajouter 2 étapes pour télécharger les versions Release et Snapshot.

 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} 

Dans cette solution, je suis allé un peu plus loin et j'ai décidé d'utiliser un modèle de CI pour les projets java.

 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 

 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 

Vers le contenu

Configuration de Pom.xml

Cette rubrique est décrite en détail par Googolplex dans Configuration du maven pour la signature automatique et le téléchargement d'artefacts dans des référentiels d'instantanés et de stockage intermédiaire , je vais donc décrire certaines des nuances de l'utilisation des plugins. Je décrirai également à quel point vous pouvez utiliser facilement et naturellement le nexus-staging-maven-plugin si vous ne voulez pas ou ne pouvez pas utiliser org.sonatype.oss: oss-parent comme parent pour votre projet.

maven-install-plugin

Installe les modules dans le référentiel local.
Très utile pour la vérification locale des solutions dans d'autres projets, ainsi qu'une somme de contrôle.

 <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> 

Vers le contenu

plugin maven-javadoc

Génération de javadoc pour le projet.

 <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> 

Si vous avez un module qui ne contient pas de java (par exemple uniquement des ressources)
Ou vous ne voulez pas générer de javadoc en principe, alors le maven-jar-plugin aidera

 <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> 

Vers le contenu

plugin maven-gpg

 <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> 

Vers le contenu

nexus-staging-maven-plugin

Configuration:

 <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> 

Si vous avez un projet multi-modules et que vous n'avez pas besoin de télécharger un module spécifique dans le référentiel, ajoutez ensuite nexus-staging-maven-plugin avec l'indicateur skipNexusStagingDeployMojo au pom.xml de ce module

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

Une fois téléchargées, les versions des instantanés / versions sont disponibles dans le référentiel intermédiaire.

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

Plus d'avantages

• Une liste très riche d'objectifs pour travailler avec le référentiel nexus ( mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin ).
• Vérifier automatiquement la libération de la capacité de téléchargement dans Maven Central

Vers le contenu

Résultat

Publier la version INSTANTANÉE

Lors de la construction d'un projet, il y a la possibilité de démarrer manuellement une tâche pour télécharger la version SNAPSHOT dans nexus

Lorsque cette tâche démarre, la tâche correspondante dans le projet de déploiement est déclenchée ( exemple ).

 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] ------------------------------------------------------------------------ 

Par conséquent, la version 1.0.0-SNAPSHOT est chargée dans nexus.

Toutes les versions d'instantanés peuvent être supprimées du référentiel sur oss.sonatype.org sous votre compte.

Vers le contenu

Publier la version finale

Lorsque la balise est installée, la tâche correspondante dans le projet de déploiement est automatiquement déclenchée pour télécharger la version finale dans nexus ( exemple ).

La meilleure partie est que la libération rapprochée dans Nexus est automatiquement déclenchée.

 [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] ------------------------------------------------------------------------ 

 [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 <a href=http://keys.gnupg.net:11371/>http://keys.gnupg.net:11371/</a>. 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] ------------------------------------------------------------------------ 

. .

,

Vers le contenu

Conclusion

Qu'avons-nous

• 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 .

Vers le contenu