Cet article s'adresse aux développeurs Java qui souhaitent publier rapidement leurs produits dans les dépÎts Sonatype et/ou Maven Central en utilisant GitLab. Dans cet article, je vais vous expliquer comment configurer gitlab-runner, gitlab-ci et le plugin Maven pour répondre à ce besoin.
Prérequis :
- Stockage sécurisé des clés mvn et GPG.
- Exécution sécurisée des tùches CI publiques.
- Téléchargement des artefacts (release/snapshot) dans les dépÎts publics.
- VĂ©rification automatique des versions release pour publication dans Maven Central.
- Solution globale pour le téléchargement d'artefacts dans un dépÎt pour plusieurs projets.
- Simplicité et facilité d'utilisation.
Contenu
Informations générales
- Une description dĂ©taillĂ©e du mĂ©canisme de publication des artefacts dans Maven Central via le service d'hĂ©bergement de dĂ©pĂŽt OSS de Sonatype est dĂ©jĂ fournie dans par l'utilisateur , donc je ferai rĂ©fĂ©rence Ă cet article lĂ oĂč c'est nĂ©cessaire.
- Tout d'abord, nous nous inscrivons sur et ouvrons un ticket pour la création du dépÎt (pour plus de détails, voir la section ). Une fois le dépÎt ouvert, les identifiants de connexion JIRA (ci-aprÚs compte Sonatype) seront utilisés pour télécharger les artefacts dans Sonatype nexus.
- Le processus de génération de la clé GPG est décrit de maniÚre assez succincte. Pour plus de détails, voir la section
- Si vous utilisez la console Linux pour générer la clé GPG (gnupg/gnupg2), il est nécessaire d'installer pour générer de l'entropie. Sinon, la génération de la clé peut prendre beaucoup de temps.
- Services de stockage des clés publiques GPG
Configuration du projet de déploiement dans GitLab
- Tout d'abord, crĂ©ez et configurez un projet oĂč le pipeline sera stockĂ© pour le dĂ©ploiement des artefacts. J'ai simplement nommĂ© mon projet â
- AprÚs avoir créé le dépÎt, il est nécessaire de restreindre l'accÚs à la modification du dépÎt.
Accédez au projet -> ParamÚtres -> DépÎt -> Branches protégées. Supprimez toutes les rÚgles et ajoutez une seule rÚgle avec un Wildcard * avec un droit de push et de merge uniquement pour les utilisateurs ayant le rÎle de Mainteneurs. Cette rÚgle sera appliquée à tous les utilisateurs de ce projet ainsi qu'au groupe auquel ce projet appartient.
- S'il y a plusieurs mainteneurs, la meilleure solution est de restreindre l'accÚs au projet en général.
Allons dans le projet -> ParamÚtres -> Général -> Visibilité, fonctionnalités du projet, permissions et définissons la visibilité du projet à Privée.
Mon projet est accessible au public, car j'utilise mon propre GitLab Runner et j'ai le droit de modifier le dĂ©pĂŽt. De plus, je n'ai aucun intĂ©rĂȘt Ă dĂ©voiler des informations privĂ©es dans des journaux de pipeline publics. - Renforcement des rĂšgles de modification du dĂ©pĂŽt
Allons dans le projet -> ParamÚtres -> DépÎt -> RÚgles de push et activons les options Restriction de committer, Vérifier si l'auteur est un utilisateur GitLab. Je recommande également de configurer , et d'activer l'option Rejeter les commits non signés. - Ensuite, il est nécessaire de configurer un déclencheur pour exécuter des tùches
Allons dans le projet -> ParamÚtres -> CI / CD -> Déclencheurs de pipeline et créons un nouveau token de déclencheur
Ce token peut ĂȘtre ajoutĂ© immĂ©diatement Ă la configuration globale des variables pour le groupe de projets.
Allons dans le groupe -> ParamÚtres -> CI / CD -> Variables et ajoutons la variableDEPLOY_TOKENavec le token de déclencheur comme valeur.
GitLab Runner
Cette section décrit la configuration pour exécuter des tùches de déploiement en utilisant un runner privé (Specific) et un runner public (Shared).
Runner spécifique
J'utilise des runners privés, car c'est avant tout pratique, rapide et peu coûteux.
Pour le runner, je recommande un VDS Linux avec 1 CPU, 2 Go de RAM, 20 Go de HDD. Le coĂ»t est d'environ 3000✠par an.
Mon runner
Pour le runner, j'ai pris un VDS avec 4 CPU, 4 Go de RAM, 50 Go de SSD. Cela m'a coĂ»tĂ© environ 11000✠et je ne l'ai jamais regrettĂ©.
J'ai au total 7 machines. 5 chez aruba et 2 chez ihor.
Donc, nous avons un runner. Maintenant, nous allons le configurer.
Connectons-nous Ă la machine via SSH et installons java, git, maven, gnupg2.
Installons GitLab Runner
- Créons un nouveau groupe
runnersudo groupadd runner - Créons un répertoire pour le cache de maven et assignons les droits au groupe
runner
Cette Ă©tape peut ĂȘtre sautĂ©e si vous ne prĂ©voyez pas de faire fonctionner plusieurs runners sur une seule machine.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - CrĂ©ons un utilisateur
gitlab-deployeret ajoutons-le au grouperunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Ajoutons au fichier
/etc/ssh/sshd_configla ligne suivanteAllowUsers root@* gitlab-deployer@127.0.0.1 - Redémarrons
sshdsystemctl restart sshd - DĂ©finissons un mot de passe pour l'utilisateur
gitlab-deployer(il peut ĂȘtre simple, car il y a une restriction pour localhost)passwd gitlab-deployer - Installons 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 - Allons sur le site gitlab.com -> déployer-projet -> ParamÚtres -> CI/CD -> Runners -> Runners spécifiques et copions le jeton d'enregistrement
Capture d'Ă©cran
- Enregistrons le runner
gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml
Processus
Plateforme d'exécution arch=amd64 os=linux pid=17594 révision=3001a600 version=11.10.0
Fonctionne en mode systĂšme.
Veuillez entrer l'URL du coordinateur gitlab-ci (ex. https://gitlab.com/):
https://gitlab.com/
Veuillez entrer le jeton gitlab-ci pour ce runner:
REGISTRATION_TOKEN
Veuillez entrer la description gitlab-ci pour ce runner:
[ih1174328.vds.myihor.ru]: Deploy Runner
Veuillez entrer les tags gitlab-ci pour ce runner (séparés par des virgules):
déployer
Enregistrement du runner... réussi runner=ZvKdjJhx
Veuillez entrer l'exécuteur : docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner enregistrĂ© avec succĂšs. NâhĂ©sitez pas Ă le dĂ©marrer, mais s'il fonctionne dĂ©jĂ , la configuration devrait ĂȘtre rechargĂ©e automatiquement!- VĂ©rifions que le runner est enregistrĂ©. Allons sur le site gitlab.com -> dĂ©ployer-projet -> ParamĂštres -> CI/CD -> Runners -> Runners spĂ©cifiques -> Runners activĂ©s pour ce projet
Capture d'Ă©cran
- Ajoutez séparé un service
/etc/systemd/system/gitlab-deployer.service[Unit] Description=Runner de déploiement GitLab 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 - Démarrons le service.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Vérifions que le runner est en cours d'exécution.
Exemple
Génération des clés GPG
- Depuis cette mĂȘme machine, connectez-vous par ssh avec l'utilisateur
gitlab-deployer(c'est important pour la génération de la clé GPG)ssh gitlab-deployer@127.0.0.1 - Générons une clé en répondant aux questions. J'ai utilisé mon propre nom et mon adresse email.
Assurez-vous de spécifier un mot de passe pour la clé. Cette clé sera utilisée pour signer les artefacts.gpg --gen-key - Vérification
gpg --list-keys -a /home/gitlab-deployer/.gnupg/pubring.gpg ---------------------------------------- pub 4096R/00000000 2019-04-19 uid Petruha Petrov sub 4096R/11111111 2019-04-19 - Téléchargeons notre clé publique sur le serveur de clés
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: envoi de la clé 00000000 au serveur hkp keys.gnupg.net
Configuration de Maven
- Connectez-vous avec l'utilisateur
gitlab-deployersu gitlab-deployer - Créons le répertoire maven répertoire et lions avec le cache (ne vous trompez pas)
Ce point peut ĂȘtre ignorĂ© si vous ne prĂ©voyez pas d'exĂ©cuter plusieurs runners sur la mĂȘme machine.mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - CrĂ©ons la clĂ© maĂźtre
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Créons le fichier ~/.m2/settings-security.xml
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Chiffrer le mot de passe du compte Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Créer le fichier ~/.m2/settings.xml
env true GPG_SECRET_KEY_PASSPHRASE sonatype SONATYPE_USERNAME {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
oĂč,
GPG_SECRET_KEY_PASSPHRASE â mot de passe de la clĂ© GPG
SONATYPE_USERNAME â identifiant du compte sonatype
La configuration du runner est maintenant terminée, vous pouvez passer à la section suivante
Runner partagé
Génération des clés GPG
- Tout d'abord, il est nécessaire de créer une clé GPG. Pour ce faire, installez gnupg.
yum install -y gnupg - Générez la clé en répondant aux questions. J'ai utilisé mon propre nom et adresse e-mail. Assurez-vous d'indiquer un mot de passe pour la clé.
gpg --gen-key - Affichez les informations de la clé
gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [expires: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp sub rsa3072 2019-04-24 [E] [expires: none] - Téléchargeons notre clé publique sur le serveur de clés
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: envoi de la clé 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 au serveur hkp 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----- - Allez dans les paramÚtres du projet -> Settings -> CI / CD -> Variables et enregistrez la clé privée dans une variable
GPG_SECRET_KEY
Configuration de Maven
- Créons la clé maßtre
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Allez dans les paramĂštres du projet -> Settings -> CI / CD -> Variables et enregistrez dans une variable
SETTINGS_SECURITY_XMLles lignes suivantes :{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Chiffrer le mot de passe du compte Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Allez dans les paramĂštres du projet -> Settings -> CI / CD -> Variables et enregistrez dans une variable
SETTINGS_XMLles lignes suivantes :env true GPG_SECRET_KEY_PASSPHRASE sonatype sonatype_username {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
oĂč,
GPG_SECRET_KEY_PASSPHRASE â mot de passe de la clĂ© GPG
SONATYPE_USERNAME â identifiant du compte sonatype
DĂ©ploiement de l'image docker
- Créons un Dockerfile assez simple pour exécuter des tùches de déploiement avec la version nécessaire de Java. Voici un exemple pour 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/ - Construisez le conteneur pour votre projet
docker build -t registry.gitlab.com/group/deploy . - Authentifiez-vous et téléchargez le conteneur dans le registre.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
GitLab CI
DĂ©ploiement du projet
Ajoutons un fichier .gitlab-ci.yml à la racine du projet de déploiement
Le script présente deux tùches mutuellement exclusives pour le déploiement : Specific Runner ou Shared Runner, respectivement.
.gitlab-ci.yml
stages:
- deploy
Specific Runner:
extends: .java_deploy_template
# La tùche sera exécutée sur votre shell-runner
tags:
- deploy
Shared Runner:
extends: .java_deploy_template
# La tùche sera exécutée sur le docker-runner public
tags:
- docker
# Image provenant de la section GitLab Runner -> Shared Runner -> Docker
image: registry.gitlab.com/group/deploy-project:latest
before_script:
# Importation de la clé GPG
- printf "${GPG_SECRET_KEY}" | gpg --batch --import
# Sauvegarde de la configuration Maven
- printf "${SETTINGS_SECURITY_XML}" > ~/ .m2/settings-security.xml
- printf "${SETTINGS_XML}" > ~/ .m2/settings.xml
.java_deploy_template:
stage: deploy
# La tùche sera déclenchée si la variable DEPLOY est fournie avec la valeur java
only:
variables:
- $DEPLOY == "java"
variables:
# désactiver le clonage du projet actuel
GIT_STRATEGY: none
script:
# Permet de stocker le mot de passe en texte clair
- git config --global credential.helper store
# Sauvegarde des crédits temporaires de l'utilisateur gitlab-ci-token
# Le token fonctionne pour tous les projets publics de gitlab.com et pour les projets de groupe
- echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/ .git-credentials
# Nettoyage complet du répertoire actuel
- rm -rf .* *
# Cloner le projet que nous déploierons dans Sonatype Nexus
- git clone ${DEPLOY_CI_REPOSITORY_URL} .
# Changer sur le commit désiré
- git checkout ${DEPLOY_CI_COMMIT_SHA} -f
# Si un pom.xml contient le paramĂštre autoReleaseAfterClose, Ă©chouer la construction.
# Sinon, il y a un risque de publier des artefacts bruts dans Maven Central
- >
for pom in $(find . -name pom.xml); do
if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
echo "Le fichier $pom contient un réglage interdit : ";
exit 1;
fi;
done
# Si le paramĂštre DEPLOY_CI_COMMIT_TAG est vide, forcer la version 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
# Lancer la tùche de construction et déploiement des artefacts
- mvn clean deploy -DskipTests=trueProjet Java
Dans les projets Java destinĂ©s Ă ĂȘtre tĂ©lĂ©chargĂ©s dans des dĂ©pĂŽts publics, il est nĂ©cessaire d'ajouter 2 Ă©tapes pour le tĂ©lĂ©chargement des versions Release et Snapshot.
.gitlab-ci.yml
Ă©tapes:
- construction
- test
- vérification
- déploiement
Publication:
étend: .déclencher_déploiement
# Exécuter la tùche uniquement sur le tag.
seulement:
- tags
Snapshot:
étend: .déclencher_déploiement
# Exécuter manuellement la tùche de publication de la version SNAPSHOT
quand: manuel
# Ne pas exécuter la tùche si un tag est défini.
sauf:
- tags
.déclencher_déploiement:
étape: déploiement
variables:
# DĂ©sactiver le clonage du projet actuel
GIT_STRATEGY: none
# Lien vers le déclencheur de la tùche de déploiement
URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
# Variables de la tùche de déploiement
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:
# Ne pas utiliser cURL, car avec les options --fail --show-error
# il ne renvoie pas le corps de la réponse si le code HTTP est 400 ou plus
- 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 CI unique pour les projets Java.
Plus de détails
J'ai créé un projet séparé dans lequel j'ai placé le modÚle CI pour les projets Java .
common.yml
Ă©tapes:
- construction
- test
- vérification
- déploiement
variables:
SONAR_ARGS: "
-Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA}
-Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME}
"
.build_java_project:
Ă©tape: construction
tags:
- touchbit-shell
variables:
SKIP_TEST: "false"
script:
- mvn clean
- mvn package -DskipTests=${SKIP_TEST}
artifacts:
when: always
expire_in: 30 jours
paths:
- "*\/target\/reports"
.build_sphinx_doc:
Ă©tape: construction
tags:
- touchbit-shell
variables:
DOCKERFILE: .indirect\/docs\/Dockerfile
script:
- docker build --no-cache -t ${CI_PROJECT_NAME}\/doc -f ${DOCKERFILE} .
.junit_module_test_run:
Ă©tape: test
tags:
- touchbit-shell
variables:
MODULE: ""
script:
- cd ${MODULE}
- mvn test
artifacts:
when: always
expire_in: 30 jours
paths:
- "*\/target\/reports"
.junit_test_run:
Ă©tape: test
tags:
- touchbit-shell
script:
- mvn test
artifacts:
when: always
expire_in: 30 jours
paths:
- "*\/target\/reports"
.sonar_review:
étape: vérification
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
.déclencher_déploiement:
étape: déploiement
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}
.déclencher_release_deploy:
étend: .déclencher_déploiement
seulement:
- tags
.déclencher_snapshot_deploy:
étend: .déclencher_déploiement
quand: manuel
sauf:
- tags
En consĂ©quence, dans les projets Java eux-mĂȘmes, le .gitlab-ci.yml apparaĂźt assez compact et peu verbeux.
.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_deployConfiguration de pom.xml
Ce sujet est décrit trÚs en détail. dans , donc je vais décrire certains aspects de l'utilisation des plugins. Je vais également expliquer comment il est facile et sans effort d'utiliser nexus-staging-maven-plugin, si vous ne souhaitez pas ou ne pouvez pas utiliser org.sonatype.oss:oss-parent comme parent pour votre projet.
maven-install-plugin
Installe des modules dans le dépÎt local.
C'est trÚs utile pour vérifier localement des solutions dans d'autres projets, ainsi qu'à des fins de validation.
org.apache.maven.plugins
maven-install-plugin
install-project
install
target/${project.artifactId}-${project.version}.jar
target/${project.artifactId}-${project.version}-sources.jar
dependency-reduced-pom.xml
true
truemaven-javadoc-plugin
Génération de javadoc pour le projet.
org.apache.maven.plugins
maven-javadoc-plugin
jar
prepare-package
true
true
falseSi vous avez un module qui ne contient pas de Java (par exemple uniquement des ressources)
Ou si vous ne voulez pas du tout générer de javadoc, alors voici une solution maven-jar-plugin
org.apache.maven.plugins
maven-jar-plugin
empty-javadoc-jar
generate-resources
jar
javadoc
${basedir}/javadocmaven-gpg-plugin
org.apache.maven.plugins
maven-gpg-plugin
sign-artifacts
deploy
signnexus-staging-maven-plugin
Configuration:
org.sonatype.plugins
nexus-staging-maven-plugin
org.sonatype.plugins
nexus-staging-maven-plugin
true
sonatype
https://oss.sonatype.org/
true
org.apache.maven.plugins
maven-deploy-plugin
true
sonatype
Nexus Snapshot Repository
https://oss.sonatype.org/content/repositories/snapshots/
sonatype
Nexus Release Repository
https://oss.sonatype.org/service/local/staging/deploy/maven2/Si vous avez un projet multi-modules et que vous n'avez pas besoin de télécharger un module spécifique dans le dépÎt, ajoutez ceci dans le pom.xml de ce module. nexus-staging-maven-plugin avec le drapeau skipNexusStagingDeployMojo
org.sonatype.plugins
nexus-staging-maven-plugin
trueAprÚs le téléchargement, les versions snapshot/release sont disponibles dans
SonatypeNexus
https://oss.sonatype.org/content/groups/staging/
Autres avantages
- Une liste trÚs riche d'objectifs pour travailler avec le dépÎt nexus (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Vérification automatique de la possibilité de téléchargement dans maven central
RĂ©sultat
Publication de la version SNAPSHOT
Lors de la construction du projet, il est possible de lancer manuellement la tùche de téléchargement de la version SNAPSHOT dans nexus
Lors de l'exécution de cette tùche, la tùche correspondante dans le projet deploy est déclenchée ().
Journal tronqué
Exécution avec gitlab-runner 11.10.0 (3001a600)
sur le runner de déploiement JSKWyxUw
Utilisation de l'exécuteur Shell...
Exécution sur ih1174328.vds.myihor.ru...
Configuration du dépÎt Git ignorée
Vérification du checkout Git ignorée
Configuration des sous-modules Git ignorée
$ 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} .
Clonage dans 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Note : vérification de '850f86aa317194395c5387790da1350e437125a7'.
Vous ĂȘtes en Ă©tat 'HEAD dĂ©tachĂ©'. Vous pouvez explorer, apporter des modifications expĂ©rimentales
et les valider, et vous pouvez supprimer toute validation que vous effectuez dans cet
Ă©tat sans impacter aucun branche en effectuant un autre checkout.
Si vous voulez créer une nouvelle branche pour conserver les validations que vous créez, vous pouvez
le faire (maintenant ou plus tard) en utilisant -b avec la commande checkout de nouveau. Exemple :
git checkout -b new_branch_name
HEAD est maintenant à 850f86a... saut de test de déploiement-core
$ for pom in $(find . -name pom.xml); do # commande multi-ligne compressée
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # commande multi-ligne compressée
[INFO] Scan des projets...
[INFO] Inspection de la construction avec un total de 4 modules...
[INFO] Installation des fonctionnalités Nexus Staging :
[INFO] ... total de 4 exécutions de maven-deploy-plugin remplacées par nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Ordre de construction du réacteur :
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Client Shields4J [jar]
[INFO] Ăcouteur TestNG [jar]
[INFO]
[INFO] -----------------------------
[INFO] Construction de Shields4J 1.0.0 [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] à la recherche de la racine agrégée locale...
[INFO] Racine d'agrégation locale : /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Traitement du changement de org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Traitement de org.touchbit.shields4j:shields4j-parent
[INFO] Mise Ă jour du projet org.touchbit.shields4j:shields4j-parent
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO]
[INFO] Traitement de org.touchbit.shields4j:client
[INFO] Mise Ă jour du parent org.touchbit.shields4j:shields4j-parent
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO] Mise à jour de la dépendance org.touchbit.shields4j:test-core
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO]
[INFO] Traitement de org.touchbit.shields4j:test-core
[INFO] Mise Ă jour du parent org.touchbit.shields4j:shields4j-parent
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO]
[INFO] Traitement de org.touchbit.shields4j:testng
[INFO] Mise Ă jour du parent org.touchbit.shields4j:shields4j-parent
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO] Mise à jour de la dépendance org.touchbit.shields4j:client
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO] Mise à jour de la dépendance org.touchbit.shields4j:test-core
[INFO] de la version 1.0.0 Ă 1.0.0-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Résumé du réacteur :
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCĂS [ 0.992 s]
[INFO] test-core .......................................... IGNORĂ
[INFO] Client Shields4J ................................... IGNORĂ
[INFO] Ăcouteur TestNG 1.0.0 .............................. IGNORĂ
[INFO] ------------------------------------------------------------------------
[INFO] CONSTRUCTION RĂUSSIE
[INFO] ------------------------------------------------------------------------
[INFO] Temps total : 2.483 s
[INFO] Terminé à : 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scan des projets...
[INFO] Inspection de la construction avec un total de 4 modules...
[INFO] Installation des fonctionnalités Nexus Staging :
[INFO] ... total de 4 exécutions de maven-deploy-plugin remplacées par nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Ordre de construction du réacteur :
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Client Shields4J [jar]
[INFO] Ăcouteur TestNG [jar]
[INFO]
[INFO] -----------------------------
[INFO] Construction de Shields4J 1.0.0-SNAPSHOT [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
SUPPRIMĂ
...
[INFO] * Déploiement groupé des artefacts de snapshot recueillis localement terminé.
[INFO] Déploiement à distance terminé avec succÚs.
[INFO] ------------------------------------------------------------------------
[INFO] Résumé du réacteur :
[INFO]
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUCCĂS [ 2.375 s]
[INFO] test-core .......................................... SUCCĂS [ 3.929 s]
[INFO] Client Shields4J ................................... SUCCĂS [ 3.815 s]
[INFO] Ăcouteur TestNG 1.0.0-SNAPSHOT ..................... SUCCĂS [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] CONSTRUCTION RĂUSSIE
[INFO] ------------------------------------------------------------------------
[INFO] Temps total : 47.629 s
[INFO] Terminé à : 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------En conséquence, la version a été chargée dans nexus .
Toutes les versions snapshot peuvent ĂȘtre supprimĂ©es du dĂ©pĂŽt sur le site sous votre compte.
Publication de la version release
Lors de l'installation de l'étiquette, une tùche correspondante est automatiquement déclenchée dans le projet de déploiement pour charger la version release dans nexus ().
Le plus agréable, c'est que la fermeture de la release dans nexus se déclenche automatiquement.
[INFO] Exécution de l'étape de mise en scÚne à distance...
[INFO]
[INFO] * Mise en scĂšne Ă distance dans le profil de mise en scĂšne ID "9043b43f77dcc9"
[INFO] * DépÎt de mise en scÚne créé avec ID "orgtouchbit-1037".
[INFO] * DĂ©pĂŽt de mise en scĂšne Ă https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO] * Téléchargement des artefacts mis en scÚne localement vers le profil org.touchbit
[INFO] * Téléchargement des artefacts mis en scÚne localement terminé.
[INFO] * Fermeture du dépÎt de mise en scÚne avec ID "orgtouchbit-1037".
En attendant la fin de l'opération...
.........
[INFO] Mise en scÚne à distance de 1 dépÎts, terminé avec succÚs.
[INFO] ------------------------------------------------------------------------
[INFO] Résumé du réacteur :
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCĂS [ 9.603 s]
[INFO] test-core .......................................... SUCCĂS [ 3.419 s]
[INFO] Client Shields4J ................................... SUCCĂS [ 9.793 s]
[INFO] TestNG listener 1.0.0 .............................. SUCCĂS [01:23 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCĂS
[INFO] ------------------------------------------------------------------------
[INFO] Temps total : 01:47 min
[INFO] Terminé à : 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------Et si quelque chose ne va pas, la tùche échouera nécessairement
[INFO] Exécution du staging à distance...
[INFO]
[INFO] * Staging Ă distance dans le profil de staging ID "9043b43f77dcc9"
[INFO] * DépÎt de staging créé avec l'ID "orgtouchbit-1038".
[INFO] * DĂ©pĂŽt de staging Ă https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO] * Téléversement des artefacts mis en staging localement vers le profil org.touchbit
[INFO] * Téléversement des artefacts mis en staging localement terminé.
[INFO] * Fermeture du dépÎt de staging avec l'ID "orgtouchbit-1038".
En attente de la fin de l'opération...
.......
[ERROR] Ăchec de la rĂšgle lors de la tentative de fermeture du dĂ©pĂŽt de staging avec l'ID "orgtouchbit-1039".
[ERROR]
[ERROR] Rapport d'Ă©chec des rĂšgles de staging Nexus
[ERROR] ==================================
[ERROR]
[ERROR] Ăchecs du dĂ©pĂŽt "orgtouchbit-1039"
[ERROR] Ăchecs de la rĂšgle "signature-staging"
[ERROR] * Pas de clĂ© publique : La clĂ© avec l'id : (1f42b618d1cbe1b5) n'a pas pu ĂȘtre localisĂ©e sur http://keys.gnupg.net:11371/. TĂ©lĂ©versez votre clĂ© publique et rĂ©essayez l'opĂ©ration.
...
[ERROR] Nettoyage du répertoire de staging local aprÚs un échec de rÚgle lors de la fermeture des dépÎts de staging : [orgtouchbit-1039]
[ERROR] * Suppression du contexte 9043b43f77dcc9.properties
[ERROR] Nettoyage des dépÎts de staging distants aprÚs un échec de rÚgle lors de la fermeture des dépÎts de staging : [orgtouchbit-1039]
[ERROR] * Suppression du dépÎt de staging échoué avec l'ID "orgtouchbit-1039" (échec de rÚgle lors de la fermeture des dépÎts de staging : [orgtouchbit-1039]).
[ERROR] Staging Ă distance terminĂ© avec un Ă©chec : Ăchec des rĂšgles de staging !
[INFO] ------------------------------------------------------------------------
[INFO] Résumé du réacteur :
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCĂS [ 4.073 s]
[INFO] test-core .......................................... SUCCĂS [ 2.788 s]
[INFO] Client Shields4J ................................... SUCCĂS [ 3.962 s]
[INFO] Ăcouteur TestNG 1.0.0 .............................. ĂCHEC [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] ĂCHEC DE LA CONSTRUCTION
[INFO] ------------------------------------------------------------------------Il ne nous reste qu'un seul choix. Soit supprimer cette version, soit la publier.
AprĂšs la publication, aprĂšs un certain temps, les artefacts seront disponibles dans
hors sujet
Pour moi, c'était une découverte que Maven indexe d'autres dépÎts publics.
J'ai dû ajouter un robots.txt, car il a indexé mon ancien dépÎt.
Conclusion
Que avons-nous ?
- Un projet de dĂ©ploiement distinct dans lequel plusieurs tĂąches CI peuvent ĂȘtre mises en Ćuvre pour tĂ©lĂ©verser des artefacts vers des dĂ©pĂŽts publics pour diffĂ©rents langages de dĂ©veloppement.
- Le projet de dĂ©ploiement est isolĂ© des interfĂ©rences extĂ©rieures et ne peut ĂȘtre modifiĂ© que par des utilisateurs ayant le rĂŽle de propriĂ©taire et de mainteneur.
- Un exécuteur spécifique distinct avec un cache « chaud » pour exécuter uniquement des tùches de déploiement.
- Publication de versions snapshot/release dans un dépÎt public.
- Vérification automatique de la version release pour préparation à la publication dans Maven Central.
- Protection contre la publication automatique de versions « brutes » dans Maven Central.
- Compilation et publication de versions snapshot « par clic ».
- Un dépÎt unique pour obtenir des versions snapshot/release.
- Pipeline général pour la construction/test/publication d'un projet Java.
La configuration de GitLab CI n'est pas un sujet aussi complexe qu'il y paraĂźt au premier abord. Il suffit de configurer CI «clĂ© en main» quelques fois et vous ne serez dĂ©jĂ plus un dĂ©butant dans ce domaine. De plus, la documentation de GitLab est trĂšs exhaustive. N'ayez pas peur de faire le premier pas. Le chemin se forme sous les pas de celui qui avance (je ne me souviens plus qui a dit ça đ ).
Je serais ravi d'avoir vos retours.
Dans le prochain article, je vais expliquer comment configurer GitLab CI pour le lancement concurrent de tùches avec des tests d'intégration (en exécutant les services à tester à l'aide de docker-compose), si vous n'avez qu'un seul runner shell.
Source : habr.com
