Cet article est un article de blog de @ takahi-i, [Téléchargement automatique des artefacts Java vers le référentiel Nexus avec Walter et Git Hooks](https://walter-cd.net/2016/11/18/automatic-upload-aritfacts- Traduction japonaise de to-nexus-repository /).

TL;DR

Le traitement interactif des plug-ins de version Maven est sujet aux erreurs et douloureux
Enregistrement automatique avec Nexus Repository (Maven Central) en utilisant Walter
Développé pour que le processus de publication s'exécute automatiquement lorsque vous vous engagez à mettre à niveau à l'aide de GitHook (des services tels que Jenkins et Tranvis ne sont pas requis)

Plug-in de version Maven

L'auteur de cet article est un membre du développement de Walter, mais écrit en Java appelé RedPen. Il est également membre du développement des outils calibrés. Les artefacts de cet outil (fichiers Jar et War) sont ajoutés au référentiel Maven Central à chaque version. Auparavant, le ** plug-in de publication ** de Maven était utilisé pour ajouter des artefacts au référentiel Maven Central.

La configuration pour utiliser le plug-in de version Maven (pom.xml '' et signature électronique) est assez difficile. Pour plus de détails, veuillez lire l'article [ici](http://samuraism.jp/diary/2012/05/03/1336047480000.html). Cependant, une fois configuré, il est pratique d'ajouter les artefacts au référentiel Maven Centaral simplement en exécutant la commande mvn release '' au moment de la publication.

Mais récemment, j'ai eu du mal à exécuter le plugin de publication pour chaque version. Par conséquent, dans cet article, nous examinerons comment automatiser le processus de publication. Mais d'abord, pensons au processus de publication à l'aide du plug-in de publication.

Traitement à l'aide du plug-in Release

Lorsque vous exécutez un plug-in de version, il effectue beaucoup de travail de manière interactive. Ce qui suit prépare le plug-in reelealse Il est dans l'état où `` release: prepare '' est exécuté.

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

Il vous sera d'abord demandé de saisir la version de la version. Le plug-in de publication présente la version de la version actuelle de l'instantané (1.7.5 dans l'exemple ci-dessus). Si la version présentée est différente de la version que vous souhaitez publier, entrez le numéro de version manuellement.

Le plug-in demande alors une future version de développement. Saisissez-le manuellement si nécessaire.

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

Une fois que cela est fait, le plug-in modifiera le numéro de version de git et s'engagera dans git. Puis construisez dans l'état actuel.

Si la construction réussit, le plug-in vous demandera de transmettre le changement de numéro de version au référentiel distant.

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

Vous pouvez voir que le nom d'utilisateur et le mot de passe GitHub sont requis. Après cela, même si mvn release: prepare réussit, vous devez toujours entrer diverses choses de manière interactive dans la prochaine commande release: perform. J'ai peur de l'avoir mal tapé et de recommencer encore et encore: peur:

Automatiser le processus de publication

Le plug-in de publication que nous avons vu dans la section précédente est difficile à utiliser en raison du travail de saisie interactif.

Cas précédent

Ainsi, lorsque j'ai tweeté s'il y avait un exemple qui résolvait ce problème, la diapositive "[Vous êtes également un développeur OSS! Divers conseils lors du téléchargement de votre propre bibliothèque dans le référentiel central Maven](http: //www.slideshare) .net / nabedge / 20140405-maven-5java) »a été enseigné. Selon la diapositive, le remplacement des commandes mvn versions: set '' et mvn deploy '' élimine le besoin d'interaction.

Essayez d'utiliser Walter

La diapositive ci-dessus utilise le serveur Jenkins pour exécuter les commandes requises. Cependant, je pensais qu'un petit outil comme RedPen serait coûteux à exécuter sur un serveur. En guise de motivation, je souhaite en quelque sorte automatiser sans gérer le serveur. Il peut également être automatisé avec un service CI externe tel que Wercker, et l'opération peut être laissée au service, donc c'est facile.

Cependant, lorsque le processus de déploiement avec ces services ne fonctionne pas bien, l'analyse et la ré-exécution des journaux (réitérer et pousser à nouveau) sont un peu difficiles, j'aimerais donc l'exécuter sur le PC local si possible.

J'ai donc laissé l'outil de construction de pipeline Walter faire ce que fait le plugin de publication. Walter énumère les commandes que vous souhaitez exécuter au format YAML. Pour plus d'informations, voir ici.

Ce qui suit est un paramètre de flux de ce que fait le plug-in de publication dans Walter.

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

Tout d'abord, mvn version '' définit la version donnée par la variable d'environnement. Enregistrez ensuite vos modifications avec git. Vous êtes maintenant prêt à enregistrer vos artefacts dans Maven Central. Dans Delopy to Sonatype, utilisez mvn clean deploy '' pour enregistrer les artefacts dans Sonatype.

Spécifiez ensuite la version de développement après la publication. Le nom de la version de développement a généralement le suffixe -SNAPSHOT ''. Tout d'abord, nous calculons le numéro de version suivant ("Flush Next Release Version Number") et spécifions cette version avec "mvn versions: set". __OUT est utilisé pour réutiliser la sortie standard utilisée dans l'étape spécifiée. Enregistrez ce fichier dans le référentiel RedPen avec le nom release.yml``.

Maintenant, tout ce que vous avez à faire est d'exécuter la commande walter -c release.yml pour terminer le processus de publication (bien que Sonatype vous oblige à fermer manuellement les artefacts).

Combiner avec Git Hook

L'exécution d'une seule commande de la manière ci-dessus termine maintenant le processus de publication. Cependant, il reste un problème. RedPen vous permet de vérifier la version avec des commandes et des serveurs. Toutes les versions utilisées par RedPen peuvent être modifiées en réécrivant une ligne dans le fichier RedPen.java. Par exemple, l'image ci-dessous montre le serveur RedPen 1.7.7.

Cependant, j'ai oublié d'augmenter le numéro de version et l'ai publié: craintif: j'ai pensé à résoudre ce problème avec GitHook.

GitHook est un mécanisme qui exécute le script spécifié lorsqu'une commande git spécifique est exécutée. Cette fois, lors de git commit, je vais essayer de faire exécuter la commande release automatiquement uniquement lorsque le message de validation est Bump version ... ''.

J'ai mis les fichiers suivants dans ./git/hooks/post-commit.

#!/bin/bash

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

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

Avec ce fichier en place, si le message de validation est "Bump vesrion" (le message de validation qui change la version de RedPen est la version de Bump), le processus de publication sera exécuté. Pour cette raison, il est possible d'éviter un accident dans lequel le processus de publication est effectué même si la version interne n'a pas été mise à jour (devrait).

à partir de maintenant

RedPen bascule le serveur d'échantillons sur Heroku (http://redpen.herokuapp.com/) vers une version plus récente chaque fois qu'un commit est poussé vers un référentiel distant. J'utilise actuellement Jenkins, mais à l'avenir, je considérerai s'il est possible d'automatiser localement le processus de commutation de l'exemple de serveur.

[JAVA] Serverless (Walter + GitHook) enregistre automatiquement les livrables dans Nexus Repository (Maven Central)