web-dev-qa-db-fra.com

Existe-t-il un moyen pour que git génère automatiquement un fichier de numéro de version pour une option --version?

J'ai un projet qui sort de la phase alpha et que je suis prêt à lancer régulièrement. Je sais que GitHub a un bouton de libération "magique" mais je n'aime généralement pas les fonctionnalités "magiques" que je ne sais pas exactement ce qu'elles font:

https://github.com/blog/1547-release-your-software

Pour autant que je sache, cette fonctionnalité de publication "magique" sur GitHub crée simplement une balise sur le référentiel source pour un certain état du code ou utilise une balise existante. Selon ce lien, les noms des balises doivent refléter le numéro de version sémantique, c'est-à-dire Major.Minor.Patch ex: v10.1.2 ou quelque chose comme ça.

Généralement, la façon acceptée par Git de faire des versions semble être de simplement créer des balises. Ce que j'aimerais faire, c'est que Git crée automatiquement une sorte de fichier dans mon arborescence de code nommé version.txt ou version.h fichier contenant le nom de la balise git que j'ai créée afin que ce fichier puisse être automatiquement généré lorsque l'utilisateur émet myporgram --version sur la ligne de commande. De préférence, je voudrais un fichier d'en-tête généré automatiquement car il est intégré au binaire lors de la construction du programme. Existe-t-il un moyen de le faire automatiquement ou dois-je transférer automatiquement le numéro de balise dans le fichier avant d'émettre la commande git tag ?

16
os x nerd

Voir Nice solution ici: https://coderwall.com/p/mk18zq/automatic-git-version-tagging-for-npm-modules

Fondamentalement, faites-le dans l'autre sens. Créez un fichier texte ou un fichier d'en-tête. Disons: Version.h:

#define VERSION 10.1.2

Et créez post-commit hook qui recherche les changements dans le fichier. Pour déployer: modifiez la version et validez le fichier. Le crochet créera une balise correspondante.

7
Igal S.

Je sais que cette question est ancienne, mais je viens de la rencontrer parce que j'essaie de faire la même chose. La seule autre réponse ici montre comment créer une nouvelle balise Git chaque fois qu'un fichier de version change, mais moi et l'OP voulons faire l'inverse: mettre à jour un fichier de code pour contenir un nouveau numéro de version chaque fois que je crée une nouvelle balise Git pour une sortie." Voici comment je l'ai fait dans mon projet C++:

Créez d'abord un fichier d'en-tête appelé, par exemple, include/myproj/git_version.hpp qui définit certaines constantes:

#pragma once
namespace myproject {
extern const int MAJOR_VERSION;
extern const int MINOR_VERSION;
extern const int PATCH_VERSION;
extern const int COMMITS_AHEAD_OF_VERSION;
extern const char* VERSION_STRING;
extern const char* VERSION_STRING_PLUS_COMMITS;
}

Deuxièmement, créez un pré-commit hook (.git/hooks/pre-commit) qui génère le fichier .cpp correspondant définissant les constantes, en utilisant la sortie de git describe:

#!/bin/bash

version_regex='v([0-9]+)\.([0-9]+)\.?([0-9]*)-([0-9]+)-g([0-9|a-z]+)'
git_string=$(git describe --tags --long)

if [[ $git_string =~ $version_regex ]]; then
    major_version="${BASH_REMATCH[1]}"
    minor_version="${BASH_REMATCH[2]}"
    patch_version="${BASH_REMATCH[3]}"
    commits_ahead="${BASH_REMATCH[4]}"
else
    echo "Error: git describe did not output a valid version string. Unable to update git_version.cpp" >&2
    exit 1
fi

version_num="${major_version}.${minor_version}.${patch_version}"
version_num_plus_commits="${version_num}+${commits_ahead}"

# Working directory of a git hook is always the root of the repo
cat > $(pwd)/src/git_version.cpp <<EOM
#include <myproject/git_version.hpp>

namespace myproject {
const int MAJOR_VERSION = $major_version;
const int MINOR_VERSION = $minor_version;
const int PATCH_VERSION = $patch_version;
const int COMMITS_AHEAD_OF_VERSION = $commits_ahead;
const char* VERSION_STRING = "${version_num}";
const char* VERSION_STRING_PLUS_COMMITS = "${version_num_plus_commits}";
}
EOM

git add $(pwd)/src/git_version.cpp

Notez que la version mise à jour du fichier git_constants.cpp sera incluse dans le cadre de la validation, donc toute validation basée sur une nouvelle balise inclura également un fichier de constantes reflétant la version dans cette balise.

Ce n'est pas parfait, car cela vous oblige à créer un nouveau commit pour mettre à jour le fichier de constantes même si tout ce que vous voulez faire est de créer une nouvelle balise (qui autrement ne nécessiterait pas de nouveau commit). D'un autre côté, cela permet à votre numéro de version dans le code de suivre le nombre de validations, ce qui est plus précis que les versions étiquetées seules.

1
Edward