Dérivation de la version d'artefact maven de la branche git

Question

Nous avons un flux de travail exigence qui signifie essentiellement que nous avons besoin d'avoir l'artefact version d'un module externe définie à partir de la branche courante dans git.

I. e. si nous sommes sur la branche master du dépôt git, j'ai besoin d' <version>master-...</version> et si nous sommes sur le bugfixX branche, j'ai besoin d' <version>bugfixX-....</version> pour l'artefact généré pour cette pom.xml.

J'ai déjà constaté que https://github.com/koraktor/mavanagaiata peut fournir le hachage SHA-1 en tant que bien et il ressort de la documentation qu'il peut également fournir à la direction générale, peut-être, si elle pourrait être menée assez tôt dans le processus, nous pourrions définir la propriété et vient de mettre <version>${our.version}</version> dans le pom. Si cela est possible, j'aimerais beaucoup voir un pom.xml (et une récompense de 500 points de bounty pour elle aussi).

Si non, je suppose que nous sommes en prétraitement ou "git checkout" faire de magie en plus avec certains des crochets (que je n'ai pas encore essayé, code du travail serait trop grand).

Nous avons un haut niveau de pom, qui peut être exécuté pour générer un fichier de propriétés dans les ".." avant de construire les modules dans lesquels cette fonctionnalité je pose la question au sujet de qui doit aller.

Toutes les suggestions sur comment résoudre ce problème?

Answer 1

En effet, Maven peut pas changer la version de son propre projet dans un run avec d'autres objectifs. De plus, autant que je sache, Maven ne supporte pas les propriétés arbitraires dans l' <version> balise. Par conséquent, une exécution séparée est nécessaire à l'exécution d'un objectif qui va modifier la version de la POM. Il existe plusieurs plugins qui peut le faire - dans ce cas, on peut utiliser l' versions:set objectif versions plugin - http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html

Donc, on peut l'exécuter comme suit par exemple:

mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$branch-SNAPSHOT

où l' $branch variable doit contenir actuelle de la branche Git nom; il peut être extraite avec de l' git rev-parse, comme ceci:

branch=$(git rev-parse --abbrev-ref HEAD)

Mais encore, il faut l'exécuter en quelque sorte. Vous pouvez le faire manuellement, mais il est lourd. Donc, je pense qu'en effet le plus robuste solution serait d'aborder ce à partir de Git côté. Qu'est - a Git crochet. Voici la Git post-checkout crochet qui va faire le travail (même code que ci-dessus avec quelques filtrage d'exécuter le crochet seulement lorsque la direction générale est vérifié, pas les fichiers individuels uniquement):

#!/bin/bash

echo 'Will change the version in pom.xml files...'

# check if the checkout was to checkout a branch
if [ $3 != '1' ]
    then echo 'git checkout did not checkout a branch - quitting';exit
fi

# get current branch name
branch=$(git rev-parse --abbrev-ref HEAD)
version=$branch-SNAPSHOT

# run maven versions plugin to set new version
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$version

echo 'Changed version in pom.xml files to $version'

Mettre ce contenu dans le fichier PROJECTDIR\.git\hooks\post-checkout le fichier. Notez que le crochet de fichier doit être exécutable à exécuter (chmod +x post-checkout).

Quelques notes à propos de l' versions plugin - il est assez souple et prend en charge de nombreuses options et ont peu d'autres objectifs qui peuvent être d'aide, en fonction de votre projet de la structure (utilisez-vous parent de chrysanthèmes ou pas, n'childs ont leurs propres versions, ou font-ils tirer de parent, etc.). Ainsi, le crochet ci-dessus peuvent être légèrement modifié pour vous soutenir spécifiques, au cas par l'utilisation d'autres objectifs d' versions plugin ou par l'ajout de paramètres supplémentaires.

Pour:

• Robuste
• Pas besoin de changer quoi que ce soit dans le pom.xml les fichiers eux-mêmes pour faire ce travail
• Cette "fonctionnalité" peut être désactivé simplement en désactivant le crochet (supprimer ou non exécutable) - encore une fois, aucun changement n'est requis dans le pom.xml

Inconvénients:

• On ne peut pas s'appliquer à d'autres d'utiliser un crochet - il doit être installé manuellement après le repo est cloné (ou, vous pouvez fournir un script pour installer le crochet si Git utilisateurs ont peur de toucher les trucs à l'intérieur .répertoire git).

Mise à JOUR

Ci-après, est le plus compliqué que la version de l'hameçon, ce qui permettra non seulement de définir la version pour le nom de la branche, mais aussi de préserver le suffixe de l'ancienne version. Par exemple, à condition ancienne version master-1.0-SNAPSHOT, la commutation de l' feature1 de la branche va changer la version du projet d' feature1-1.0-SNAPSHOT. Ce script bash souffre de quelques problèmes (nécessite les noms de branche sans dash symbole (-) dans le nom, et prend seulement la version de la racine pom), mais peut donner une idée de la façon dont le crochet peut être prolongée: étant donné un mélange de mvn et de commandes bash, vous pouvez extraire et mettre à jour beaucoup de l'information dans le POM.

#!/bin/bash

echo 'Will change the version in pom.xml files...'

# check if the checkout was to checkout a branch
if [ $3 != '1' ]
    then echo 'git checkout did not checkout a branch - quitting';exit
fi

# get current branch name
branch=$(git rev-parse --abbrev-ref HEAD)

# get current version of the top level pom
current_version=$(mvn help:evaluate -Dexpression=project.version | grep -v '\[.*')

# extract version suffix
suffix=$(echo $current_version | cut -d \- -f 2)

# build new version
version=$branch-$suffix

# run maven versions plugin to set new version
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$version

echo 'Changed version in pom.xml files to $version'

Answer 2

S'il est suffisant de définir la balise git et les informations de version dans le nom du fichier d'artefact, vous pouvez utiliser maven-jgit-buildnumber-plugin :

 <build>
  <finalName>${artifactId}-${git.buildnumber}</finalName>
  <plugins>
    <plugin>
      <groupId>ru.concerteza.buildnumber</groupId>
      <artifactId>maven-jgit-buildnumber-plugin</artifactId>
      <version>1.2.7</version>
      <executions>
        <execution>
          <id>git-buildnumber</id>
          <goals>
            <goal>extract-buildnumber</goal>
          </goals>
          <phase>prepare-package</phase>
        </execution>
      </executions>
    </plugin>
    <!-- more plugins -->
  </plugins>
</build>
 

Answer 3

Avez-vous essayé d'utiliser ce plugin?: https://github.com/ktoso/maven-git-commit-id-plugin. Vous pouvez le configurer pour générer un fichier de propriétés avec toutes les informations pertinentes au sujet de vos pensions de l'etat:

• branche
• décrire
• commitId
• buildUserName
• buildUserEmail
• compilation
• commitUserName
• commitUserEmail
• commitMessageShort
• commitMessageFull
• commitTime

Answer 4

Avez-vous vérifié le buildnumber-maven-plugin qui vous donne l’occasion d’utiliser le numéro de révision de git. Mais vous aviez besoin de quelque chose de différent. En outre, je suggérerais de faire une chose comme:

    1.0.0-SNAPSHOT 
   1.0.0-SNAPSHOT 
 

être maître

sur une branche, vous pouvez simplement changer la version

   1.0.0-BF-SNAPSHOT