Meilleur moyen d'augmenter le numéro de build?

133

J'ai utilisé un script shell dans le cadre de mon processus de construction Xcode pour incrémenter le numéro de construction dans le fichier plist , mais cela fait fréquemment planter Xcode 4.2.1 (avec une erreur concernant la cible n'appartenant pas à un projet; je suppose le changement du fichier plist est en quelque sorte déroutant Xcode).

Le script shell a fait cela pour que le numéro de build ne soit incrémenté que agvtoollorsqu'un fichier est plus récent que le fichier plist (donc juste la construction n'a pas incrémenté la valeur):

if [ -n \"`find ProjDir -newer ProjDir/Project-Info.plist`\" ]; then agvtool -noscm next-version -all; else echo \"Version not incremented\"; fi

Existe-t-il un moyen d'incrémenter le numéro de build (dans le fichier plist , ou ailleurs) qui ne rompt pas Xcode?

EDIT FINAL : Je fais maintenant ce genre de choses en utilisant un script python que je viens de rendre public sur github . Ce n'est pas bien documenté mais ne devrait pas être difficile à résoudre. En prime, ce dépôt contient également un script utile pour regrouper automatiquement une bibliothèque tierce dans un ensemble d'applications.

cheval de Troie
la source
1
Si quelqu'un est intéressé: j'ai modifié un peu le script pour utiliser des nombres hexadécimaux au lieu de nombres décimaux - gist.github.com/sascha/5398750
Sascha
1
Vous pouvez ajouter ce script directement en tant qu'action de pré-construction, pas besoin d'appeler un script externe. N'exécutez pas ce script avec une phase de construction; Xcode ne copiera le plist mis à jour que toutes les autres constructions.
Ed McManus
3
Prêt à l'emploi J'ai reçu une erreur "permission refusée", alors j'ai pensé que je signalerais cette question à toute autre personne qui éprouve la même chose: stackoverflow.com/q/9850936/519030
Jason
Ce script échoue avec un code de sortie 1. Quelqu'un peut-il m'aider?
Robert J. Clegg
@Tander On dirait que vous ne fournissez pas le fichier plist comme argument du script.
trojanfoe

Réponses:

29

Si je comprends bien votre question, vous souhaitez modifier le Project-Info.plistfichier, qui fait partie du modèle de projet standard de Xcode?

La raison pour laquelle je pose cette question est que Project-Info.plistnormalement est sous contrôle de version, et le modifier signifie qu'il sera marqué comme, bien, modifié.

Si cela vous convient, alors l'extrait de code suivant mettra à jour le numéro de build et marquera le fichier comme modifié dans le processus, où se get_build_numbertrouve un script (c'est-à-dire un espace réservé dans cet exemple) pour obtenir le numéro de build (éventuellement incrémenté) que vous voulez utiliser:

#!/bin/sh

# get_build_number is a placeholder for your script to get the latest build number
build_number = `get_build_number`

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion ${build_number}" ProjDir/Project-Info.plist

PlistBuddy vous permet de définir n'importe quelle clé dans un fichier plist, pas seulement le numéro de version. Vous pouvez créer tous les fichiers plist de votre choix et les inclure dans les ressources si nécessaire. Ils peuvent ensuite être lus à partir du bundle.

Quant à votre besoin d'afficher la version dans le volet à propos et à d'autres endroits, vous pouvez également examiner les paramètres CFBundleGetInfoStringet CFBundleShortVersionString.

Monolo
la source
Je n'ai pas besoin du commit git (ou de la balise) dans le fichier plist , donc un simple système d'incrémentation convient (comme fourni par agvtool), mais le fait de modifier le plist pendant la construction rompt fréquemment Xcode (depuis la suppression du script qu'il n'a pas) t s'est écrasé une fois, alors qu'il plantait toutes les 3 versions environ) Est-il possible de mettre les informations de version dans un autre fichier plist et de l'inclure dans le bundle et accessible depuis l'application?
trojanfoe
Excellent script - je préférerais combiner cela avec la suggestion de Hugues BR de ne l'utiliser que lors de l'archivage des builds. Maintient les chiffres bas et ignore le nombre de builds de développement effectués entre les versions.
Jay
5
Qu'est-ce que get_build_number? Est-ce juste un espace réservé?
chrisp
Oui, get_build_numberc'est juste un espace réservé - a mis à jour la réponse pour clarifier.
Monolo
72

J'ai dérangé beaucoup de réponses à cette question, et aucune d'entre elles ne m'a tout à fait satisfait. Cependant, j'ai finalement trouvé un mélange que j'aime beaucoup!

Il y a deux étapes, une au début et une à la fin de vos phases de construction.

Au début:

# Set the build number to the count of Git commits
if [ "${CONFIGURATION}" = "Release" ]; then
    buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

À la fin:

# Set the build number to "DEVELOPMENT"
if [ "${CONFIGURATION}" = "Release" ]; then
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

En regardant Info.plist dans Xcode, vous verrez que le numéro de version est "DEVELOPMENT", mais l'application construite aura un numéro de version en constante augmentation. (Tant que vous faites toujours vos builds à partir de la même branche.)

La définition du numéro de version sur une chaîne constante à la fin empêche le fichier Info.plist d'être modifié en créant l'application.

Pourquoi j'aime cette méthode:

  • Facile
  • Ne pollue pas l'historique des versions de Git
  • CFBundleVersion est totalement automatique
  • Le joli numéro de version peut être modifié quand je veux
Wil Gieseler
la source
Garder les numéros de version hors du fichier plist contrôlé par version est la meilleure façon de le faire, en particulier si vous avez un brach par version et que vous avez parfois besoin de fusionner ou de choisir. Merci!
Matthew Phillips
14
Vous pouvez utiliser à la git rev-list --count HEADplace de git rev-list HEAD | wc -l | tr -d ' '.
kennytm
Hmm. J'ai trouvé que si vous utilisez fastlanepour télécharger des builds automatiques de cette façon, vous obtenez: ERREUR ITMS-90058: "Ce bundle n'est pas valide. La valeur de la clé CFBundleVersion [DEVELOPMENT] dans le fichier Info.plist doit être une liste séparée par un point de at la plupart des trois entiers non négatifs. "
fatuhoku
1
Je ne sais pas exactement où il doit aller, j'ai mis le premier script comme première phase de construction, et le dernier script comme dernière phase de construction et cela fonctionne pour moi.
Wil Gieseler
1
Vous pouvez certainement engager Info.plist en utilisant cette solution - c'est tout le point. Info.plist est toujours défini et archivé avec le numéro de version défini sur "DEVELOPMENT", il est temporairement modifié pendant le processus de construction, puis remis à nouveau sur "DEVELOPMENT" afin qu'Info.plist soit stable.
Wil Gieseler
38

J'ai utilisé cette lueur. Cela fonctionne comme prévu. https://gist.github.com/sekati/3172554 (tout le mérite revient à l'auteur original)

Des scripts que j'ai modifiés au fil du temps.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Comme ces éléments essentiels aident la communauté des développeurs, j'en ai fait un projet GitHub. Alors développons-le bien. Voici le projet GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

J'ai mis à jour le code pour les deux scripts un peu d'amélioration. au lieu d'utiliser ci-dessous, récupérez la dernière sur GitHub

Pour la version:

# xcode-version-bump.sh
# @desc Auto-increment the version number (only) when a project is archived for export. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Check the checkbox "Run script only when installing"
# 6. Drag the "Run Script" below "Link Binaries With Libraries"
# 7. Insure your starting version number is in SemVer format (e.g. 1.0.0)

# This splits a two-decimal version string, such as "0.45.123", allowing us to increment the third position.
VERSIONNUM=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${PROJECT_DIR}/${INFOPLIST_FILE}")
NEWSUBVERSION=`echo $VERSIONNUM | awk -F "." '{print $3}'`
NEWSUBVERSION=$(($NEWSUBVERSION + 1))
NEWVERSIONSTRING=`echo $VERSIONNUM | awk -F "." '{print $1 "." $2 ".'$NEWSUBVERSION'" }'`
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $NEWVERSIONSTRING" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Pour construire:

# xcode-build-bump.sh
# @desc Auto-increment the build number every time the project is run. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below into new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Ensure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
Alix
la source
Cela incrémentera toujours le numéro de build, alors que je voulais qu'il ne s'incrémente que si un fichier source change. C'est juste le script que j'utilise actuellement avec moins de contrôles de sécurité et qui discerne moins ce qui a changé.
trojanfoe
XCode 5: Editeur (barre de menus) → Ajouter une phase de construction → Ajouter une copie de fichiers Phase de construction:
Jonny
@trojanfoe: Vous pouvez exécuter ce script en tant que hook post-commit. Ce scénario n'augmentera que le numéro de build lorsque vous validerez votre code dans le dépôt. La réponse ci-dessous de LostInTheTrees est quelque chose de plus que vous voudrez peut-être faire.
Alix le
Les scripts shell liés par @Alix sont maintenant assez différents de ceux publiés ici. Pour incrémenter le numéro de build uniquement lors de la création d'une archive, vous pouvez utiliser l'essentiel que j'ai fait, très basé sur les scripts d'Alix ci-dessus, ici: gist.github.com/mattpotts/abcffea6d08ad45739ef
Matthieu
14

Toute cette entrée a été extrêmement utile. J'ai utilisé cette astuce mais j'ai configuré mon script en tant que hook post-commit dans GIT, donc CFBundleVersion est incrémenté après chaque validation réussie. Le script hook va dans .git / hooks. Un journal est laissé dans le répertoire du projet.

Cela répond à mon critère le plus élémentaire. Je veux pouvoir extraire une version de GIT et reconstruire la version exacte que j'avais précédemment. Tout incrément effectué pendant le processus de génération ne le fait pas.

Voici mon script:

#!/bin/sh
#
# post-commit
#
# This script increments the CFBundleVersion for each successful commit
#

plist="./XYZZY/XYZZY-Info.plist"
buildnum=$(/usr/libexec/Plistbuddy -c "Print CFBundleVersion" "$plist")
if [ -z "$buildnum" ]; then
    exit 1
fi
buildnumplus=$(expr $buildnum + 1)
/usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnumplus" "$plist"

echo $(date) "- Incremented CFBundleVersion to" $buildnumplus >> hookLog.txt
LostInTheTrees
la source
J'ai la même exigence, ce qui est la raison pour laquelle le numéro de build est uniquement incrémenté si un fichier source a été modifié. J'ai trouvé que cela fonctionnait très bien et je n'ai pas eu à modifier le bump_build_number.shscript depuis la création.
trojanfoe
14

Je ne sais pas quel est le meilleur moyen, mais je publierai la réponse d'Apple au cas où quelqu'un la chercherait ...

Selon cet article de questions-réponses d'Apple :

Automatiser les numéros de version et de build à l'aide d'agvtool

Les clés de version et de numéro de build spécifient respectivement les versions marketing et interne de votre application. agvtool est un outil de ligne de commande qui vous permet d'incrémenter automatiquement ces nombres jusqu'au nombre le plus élevé suivant ou à un nombre spécifique.

Le numéro de build identifie une version non publiée ou publiée de votre application. Il est stocké dans Info.plist de votre application en tant que CFBundleVersion(version Bundle).

Vous devez effectuer les étapes suivantes dans votre projet Xcode:

  1. Activer agvtool

Accédez au volet Paramètres de construction de votre cible, puis mettez-le à jour pour toutes vos configurations de construction comme suit:

  • Définissez la version actuelle du projet sur une valeur de votre choix.

Le fichier de données de votre projet Xcode, project.pbxproj, comprend un CURRENT_PROJECT_VERSIONparamètre de construction (Version actuelle du projet), qui spécifie la version actuelle de votre projet. agvtool recherche project.pbxproj CURRENT_PROJECT_VERSION. Il continue de fonctionner s'il CURRENT_PROJECT_VERSIONexiste et s'arrête, sinon. Sa valeur est utilisée pour mettre à jour le numéro de build.

  • Définissez le système de gestion des versions sur Apple Generic.

Par défaut, Xcode n'utilise aucun système de contrôle de version. La définition du système de gestion des versions sur Apple Generic garantit que Xcode inclura toutes les informations de version générées par agvtool dans votre projet.

Définir le système de gestion des versions sur Apple Generic

  1. Configurez votre version et vos numéros de build

agvtool recherche dans l'Info.plist de votre application votre version et les numéros de build. Il les met à jour s'ils existent et ne fait rien, sinon. Assurez-vous que les clés CFBundleVersion(Bundle version) et CFBundleShortVersionString(Bundle versions string, short) existent dans votre Info.plist, comme indiqué dans l'image ci-dessous:

Configurez votre version et vos numéros de build

Quittez Xcode, puis accédez au répertoire contenant votre fichier de projet .xcodeproj dans l'application Terminal avant d'exécuter l'une des commandes suivantes. Le fichier de projet .xcodeproj contient project.pbxproj, qui est utilisé par agvtool. (C'est la partie que vous pouvez exécuter dans un script au lieu de la ligne de commande.)

Mise à jour du numéro de version

Pour mettre à jour le numéro de version vers une version spécifique, exécutez

xcrun agvtool new-marketing-version <your_specific_version>

Ex: mettez à jour le numéro de version à 2.0

xcrun agvtool new-marketing-version 2.0

Mise à jour du numéro de build

Pour incrémenter automatiquement votre numéro de build, exécutez

xcrun agvtool next-version -all

Pour définir le numéro de build de votre application sur une version spécifique, exécutez

xcrun agvtool new-version -all <your_specific_version>

Ex: définissez le numéro de build sur 2.6.9

xcrun agvtool new-version -all 2.6.9

Prime:

Pour afficher le numéro de version actuel, exécutez

xcrun agvtool what-marketing-version

Pour afficher le numéro de version actuel, exécutez

xcrun agvtool what-version
FormigaNinja
la source
7
Le problème avec celui-ci est qu'agvtool abandonnera la construction de xcode afin qu'il ne puisse pas être intégré en tant que script dans les phases de construction.
Daniel Schlaug
1
Ne pourriez-vous pas simplement mettre bump via agvtool dans les pré-actions de construction du schéma?
lottadot
11

FWIW - c'est ce que j'utilise actuellement pour augmenter le numéro de version uniquement pour les versions de version (qui comprend l'archivage). Fonctionne très bien sous Xcode 5.1.

Copiez / collez simplement l'extrait de code dans une phase de création de script d' exécution directement dans Xcode:

buildnum=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$PRODUCT_SETTINGS_PATH")

if [ "$CONFIGURATION" = "Release" ]; then
buildnum=$((buildnum + 1))
echo "Build number updated to $buildnum"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildnum" "$PRODUCT_SETTINGS_PATH"
fi;
Geai
la source
Comment pouvez-vous incrémenter CFBundleVersion? Dans Xcode 5.1, c'est une chaîne au format "1.0"?
chrisp le
1
Enfin, quelqu'un le fait correctement :) Pourquoi me soucierais-je de chaque build que j'exécute sur mon appareil de développement? Les versions (et les versions destinées aux testeurs) comptent, et non les versions "hmm, déplacez ces 2px vers la gauche".
uvesten
7

Merci pour le script. Cela fonctionne très bien.

Mon Info.plist se trouve dans un sous-répertoire avec un nom contenant des espaces, j'ai donc dû modifier le Run Script avec des guillemets autour du chemin plist:

${PROJECT_DIR}/tools/bump_build_number.sh "${PROJECT_DIR}/${INFOPLIST_FILE}"

et le script shell de la même manière avec des guillemets autour de tous les chemins:

#!/bin/sh

if [ $# -ne 1 ]; then
    echo usage: $0 plist-file
    exit 1
fi

plist=$1
dir=$(dirname "$plist")

# Only increment the build number if source files have changed
if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
    buildnum=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$plist")
    if [ -z "$buildnum" ]; then
        echo "No build number in $plist"
        exit 2
    fi
    buildnum=$(expr $buildnum + 1)
    /usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnum" "$plist"
    echo "Incremented build number to $buildnum"
else
    echo "Not incrementing build number as source files have not changed"
fi
massimobio
la source
Ouais, ça a du sens. Heureux que vous le trouviez utile; J'utilise depuis sans aucun problème sous Xcode 4. {2,3,4,5}.
trojanfoe
Je me serais sauvé quelques heures si j'avais vu cette réponse! Notez également que le numéro de build ne doit pas avoir de décimal, sinon BASH croke.
Brenden
6

Le script que j'utilise actuellement est très basé sur celui d' Alix , ci-dessus. Mon adaptation, ci-dessous, ajoute une vérification pour ne faire l'auto-incrémentation que sur une version de version / archive.

Sans ce changement, il y aura des conflits de contrôle de version car chaque développeur incrémentera le numéro de build à son propre rythme. Et le fait que l'historique de git serait inutilement pollué avec le numéro de build changeant tout le temps.

# xcode-build-bump.sh
# @desc Auto-increment Xcode target build number every time the project is archived
# @src stackoverflow.com/a/15483906
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Insure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

if [ "Release" != "${CONFIGURATION}" ]
then
    exit 0
fi

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Il est également disponible (dans un format légèrement plus facile à copier et coller) sous la forme d'un gist GitHub .

Matthieu
la source
5

Je recommanderais l'utilisation de l' autorevision .

Xcode permet à un fichier d'en-tête (qui peut être généré automatiquement au moment de la construction et non dans le vcs lui-même) pour fournir des valeurs qui seront développées dans le fichier info.plist au moment de la construction. Vous pouvez trouver une procédure pas à pas pour configurer cela sur le site Web de la visualisation automatique .

Autorevision a un type de sortie orienté vers ces types de fichiers d'en-tête pour aider exactement dans ces situations.

dak180
la source
1
Autorevisionne semble pas modifier un numéro de build, comme requis?
trojanfoe
En supposant que l'on ne construit que sur un nouveau commit, alors VCS_NUMdevrait être ce que vous recherchez ( voir autorevision.hun exemple ).
dak180
Vienna-Info.plist et Vienna-All.xcconfig sont un bon exemple de la façon dont on peut configurer cela dans n'importe quel projet xcode.
dak180 le
4

Un problème avec certaines de ces solutions est que Launch Services ne reconnaît que quatre cinq chiffres majeurs dans la version du bundle . J'ai un projet avec un numéro de build qui se chiffre en milliers, donc je voulais utiliser certains des chiffres les moins significatifs.

Ce script Perl incrémente tous les Info.plists dans le projet, pas seulement celui de la cible actuelle, de sorte que les numéros de build restent tous au même niveau. Il utilise également un chiffre de correctif et deux chiffres mineurs, donc la version 1234 est donnée à la version 1.23.4. Je l'utilise comme comportement pré-build, donc il s'applique à tous les projets que je construis.

Le script est assez brutal, mais cela fonctionne pour moi.

#!/usr/bin/perl

use strict;
use warnings;
use v5.12.0;

use Dir::Iterate;

for my $plist_file(grepdir { /-Info.plist$/ } '.') {
    my $build = `/usr/libexec/PlistBuddy -c "Print CFBundleVersion" '$plist_file'`;
    chomp $build;

    next unless $build;

    # Strip dots
    $build =~ s/\.//g;
    $build =~ s/^0//g;

    # Increment
    $build++;

    # Re-insert dots
    $build =~ s/^(\d{0,4}?) (\d{0,2}?) (\d{0,1}?)$/$1.$2.$3/x;

    # Insert zeroes
    $build =~ s{(^|\.)\.}{${1}0.}g;

    system qq(/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build" '$plist_file');
}
Brent Royal-Gordon
la source
Le message que vous citez indique que « En fait, LS attend le format suivant: nnnnn [.nn [.nn]] [X] où n est un chiffre 0-9, les crochets indiquent les composants facultatifs et X est une chaîne non commençant par un chiffre. X est ignoré lorsqu'il est présent. '- donc c'est 99999 builds. Devrait être suffisant pour la plupart des projets ..?
Jay
@Jay, j'ai apparemment mal interprété cela avec quatre chiffres. Oups. (Pourtant, si votre style de développement implique beaucoup d'ajustements et de reconstructions, il n'est pas inconcevable que vous puissiez atteindre 100000 builds après des années de développement sur un projet.)
Brent Royal-Gordon
@ BrentRoyal-Gordon True - J'ai peaufiné mon script de construction pour incrémenter les versions uniquement pour les configurations de publication. beaucoup d'espace pour la tête avec de nouveaux projets Cocoa ;-)
Jay
4

Vous pouvez utiliser le contrôle de version générique d'Apple . En gros, tout ce que vous avez à faire est d'appeler agvtool next-version -alldepuis le répertoire qui héberge votre fichier .xcproj. Pour plus de détails, consultez l'url ci-dessus.

Valentin Radu
la source
3
Le problème avec cette solution est que l'appel de agvtool à partir d'un script dans le projet annulera votre build. Ce n'est pas une bonne solution à moins que vous ne trouviez une solution de contournement pour cela.
Dan Loewenherz
3

En m'appuyant sur la solution de Wil Gieseler , je n'avais qu'un seul changement à apporter. Sa solution place le nombre de commits git dans le numéro de build. Utile, mais toujours un peu pénible pour trouver le commit réel qui a créé cette construction. Je ne me souciais pas trop de savoir si le numéro de build augmentait de manière monotone, et j'ai donc abandonné cette exigence afin de pouvoir accéder plus facilement au commit qui générait un binaire donné.

À cette fin, j'ai modifié son premier script comme suit:

# Set the build number to the decimal conversion of the short version of the current git SHA

# Get the short version of the current git SHA in hexadecimal
SHA=$(git rev-parse --short @)
# Uppercase any alphabetic chars in SHA (bc doesn't like lowercase hex numbers)
UPPERCASE_SHA=$(tr '[:lower:]' '[:upper:]' <<< "$SHA")
# Use bc to convert the uppercase SHA from hex to decimal
BUILD_NUM=$(bc <<< "ibase=16;obase=A;$UPPERCASE_SHA")
# Set our build number to that
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUM" "${PROJECT_DIR}/${INFOPLIST_FILE}"

# To convert a build number back to a usable git SHA, run the following, substituting the build number for <build number>
# bc <<< "ibase=10;obase=16;<build number>"

Cela convertit la version courte de l'actuel git SHA en décimal. Les caractères hexadécimaux ne fonctionnent pas bien avec les exigences de numéro de version d'Apple, c'est pourquoi j'ai dû le faire. Pour le reconvertir, exécutez simplement quelque chose comme ceci:

SHA=$(bc <<< "ibase=10;obase=16;<build number>")

dans bash, où <build number>est le numéro de build que vous avez obtenu d'un binaire. Ensuite, courez git checkout $SHA, et voilà.

Comme il s'agit d'une adaptation de la solution de Wil Gieseler , comme mentionné ci-dessus, vous aurez également besoin du script post-build suivant:

# Set the build number to "DEVELOPMENT"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"

ce qui garde votre historique git propre.

Ravron
la source
Alors, comment cela fonctionne, étant donné que vous allez écrire les informations git dans Info.plist, qui sont elles-mêmes suivies par git?
trojanfoe
@trojanfoe Comme je l'ai mentionné en haut de la réponse, cette réponse est une adaptation de la solution de Wil Gieseler. En tant que tel, il nécessite le même script de post-construction que celui utilisé ici. J'ai ajouté cela à la réponse explicitement.
ravron
2

J'ai essayé la procédure modifiée et cela n'a pas fonctionné, car: -

  1. Xcode 4.2.1 modifie le sous-répertoire xcuserdata dans .xcodeproj

  2. git note le changement précédent dans Project-Info.plist

La modification suivante les fait ignorer et ne signale que les changements authentiques: -

if [ -n "$(find $dir \! -path "*xcuserdata*" \! -path "*.git" -newer $plist)" ]; then
Milliways
la source
2

Vous voudrez peut-être faire cela uniquement lorsque vous archivez (et téléchargez sur TF par exemple). Sinon, votre numéro de version pourrait augmenter très rapidement.

Dans le schéma (Produit / Modifier le schéma / Archiver / Pré-actions), vous pouvez ajouter un script qui ne sera exécuté que lors de l'archivage.

En outre, vous souhaiterez peut-être réinitialiser le numéro de version chaque fois que vous incrémentez la version de l'application.

Dernière chose, si vous utilisez plutôt l'archive, vous pouvez désactiver en toute sécurité:

# if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
...
# else
    # echo "Not incrementing build number as source files have not changed"
# fi

Comme le numéro de build ne sera incrémenté que lorsque vous archivez ...

EDIT: Corrigez ce que j'ai dit, les pré-actions dans l'archive se produisent après la construction (mais avant l'archivage), donc le numéro de build sera incrémenté pour la prochaine archive ... Mais vous pouvez créer un nouveau schéma et ajouter cette action dans la build (pré- actions) de ce nouveau schéma. et utilisez ce schéma lorsque vous souhaitez créer une nouvelle version

Hugues BR
la source
1
Ouais ça monte rapidement (5500+ pour le moment), mais ce n'est pas un problème pour moi; ce n'est qu'un nombre. Il est intéressant de savoir combien de fois Cmd-B / Cmd-R est touché avant que quoi que ce soit ne fonctionne même si ...
trojanfoe
2

J'utilise la dernière révision SVN pour le numéro de build. Si vous modifiez le fichier Info.plist dans le répertoire de construction, vous n'affecterez pas le fichier Info.plist source:

# use the last SVN revision as the build number:
Info_plist="$BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/Info.plist"
defaults write "${Info_plist}" CFBundleVersion `svn stat -u | awk '/'"Status against revision:"'/ {print $4}'`
jack
la source
2

J'ai l'impression d'avoir trouvé ma tribu. Tribe, j'espère que vous êtes amusé par VersionX.

Il y a dix ans, alors que je travaillais sur un espace de travail contenant plus de 25 projets Xcode, j'ai profité de l'occasion pour automatiser la version et créer des mises à jour de chaînes à un degré qui peut sembler absurde, si vous ne maintenez qu'un ou deux projets avec des mises à jour occasionnelles.

VersionX:

  • est conscient du type de construction (Release / Debug)
  • recueille des informations au moment de la construction à partir du référentiel (support git inclus, mais peut être personnalisé pour hg, svn ou tout ce que vous utilisez)
  • fourni des chaînes de version marketing de fantaisie facilement personnalisables (qui avaient beaucoup plus de variations avant que l'App Store n'impose une convention) afin que vous puissiez automatiquement incrémenter les chaînes qui incluaient des symboles pour une "bêta" en utilisant une convention de balise git, par exemple.
  • inclut une classe remplie de variables d'instance contenant des informations de version et de validation. Ceci est utile pour remplir votre panneau À propos et créer des chaînes de journalisation, des rapports d'incident ou des rapports de bogue par e-mail d'utilisateur avec des informations pré-remplies.

C'était amusant à faire. J'ai appris beaucoup de choses sur le système de construction Xcode.

Voici un exemple du type de chaînes de version fantaisie et de construction que VersionX pourrait générer automatiquement.

VersionX 1.0.1 β7 (c5959a3 «Clean»)

Version marketing: VersionX 1.0.1 β7 Le "1.0.1 est dérivé de la balise pour le commit, tandis que le" Beta 7 "est automatiquement généré par le nombre de commit, ou le nombre de build (par exemple).

Version de build: (c5959a3 «Clean») Affiche le hachage de validation court et vous informe que le répertoire de build ne comportait aucune modification non validée.

VersionX (source sur GitHub) - un système baroque pour incrémenter automatiquement la version et créer des chaînes dans les projets Xcode.

La documentation VersionX.

Gary W. Longsine
la source
1

Vous voudrez peut-être consulter un nouvel outil que j'ai développé appelé Xcodebump. Il peut gérer la mise à jour de CFBundleShortVersionString et CFBundleVersion. En guise d'étape finale, il vérifiera également git et marquera le commit pour qu'il corresponde à ces valeurs CFBundle.

Le projet Xcodebump se trouve ici:

https://github.com/markeissler/Xcodebump

Markeissler
la source
1

Je mets à jour build numberen suivant la méthode.

$INFO_FILEest le chemin du fichier plist. Et $build_numberc'est un nouveau numéro de construction pour ce bâtiment.

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build_number" "${INFO_FILE}"

Généralement, my $build_numberest composé de majoret de minorparties. Cela minorprovient des informations du projet. Je décris donc comment générer la majorpièce.

## Composed by `major` and `minor`. 
## `minor` is parsed from project information. It's another story.
## Examples: `21.1`, or `21.1.3`
build_number="${major_number}.${minor_number}"

J'ai 2 stratégies pour décider du $build_number.

Première stratégie

Cette stratégie utilise le git tagdécompte pour décider du majorde build number. S'il y a des 53balises du projet, il reviendra 53en suivant le script shell.

Généralement, il augmente. Et cela obligera le développeur à mettre une balise git avant la publication.

major_number=$(git tag -l | wc -l | grep -oE "\d+")

Deuxième stratégie

Laissez le système Jenkins CI décider de la majorpièce. Il a une variable d'environnement BUILD_NUMBER. Il augmente automatiquement lors de la construction du système CI. Ces informations sont utiles pour retracer l'historique du projet sur le système CI.

major_number=${BUILD_NUMBER}
AechoLiu
la source
1

Voici une version mise à jour. Cela fonctionne à partir de Xcode 9.3.1, iOS 11.

Cliquez sur 'Build Phases' à partir de votre application cible, cliquez sur l'icône + pour ajouter un nouveau script d'exécution, et dans la case, collez ce code.

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Allez dans le fichier Info.plist et définissez la «version du bundle» sur 1 et la «chaîne de versions du bundle, courte» sur 1, vous devriez être défini.

Générez le projet avec Info.plist en vue, et vous devriez voir le changement de version du bundle (numéro de build).

  • Notez qu'à partir de Xcode 9.3.1, vous ne pourrez pas voir ces modifications à partir de l'onglet général, mais vous verrez les modifications lorsque vous archivez une compilation et dans Info.plist
L. Davis
la source
0

Voici ma solution. Si vous êtes comme moi: compatible avec les terminaux, comme ruby, comme le versionnage sémantique, essayez ceci.

Créez un fichier nommé Rakefilequi contient ceci:

require "xcodeproj"
require "versionomy"

XCODEPROJECT = "MyProject.xcodeproj"
INFOPLISTFILE = "MyProject/MyProject-Info.plist"

$UPDATES = [:major,:minor,:tiny]
$UPDATES.each { |part|
  desc "increment #{part} part of version"
  task "increment:#{part}" do |task|
    version=`/usr/libexec/Plistbuddy -c "Print CFBundleVersion" #{INFOPLISTFILE}`.chomp
    version=Versionomy.parse(version)
    version=version.bump(part)

    # I use the same string for CFBundleVersion and CFBundleShortVersionString for now
    `/usr/libexec/PlistBuddy -c "Set :CFBundleVersion #{version}" #{INFOPLISTFILE}`
    `/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString #{version}" #{INFOPLISTFILE}`
    print "version upgraded to #{version}\n"
  end
}

Préparer: gem install xcodeproj versionomy

Exécutez: rake increment:majorou rake increment:minorou rake increment:tinyquand vous le souhaitez.

purée
la source
0

Je trouve plus pratique d'utiliser l' automatisation des numéros de version et de construction à l'aide d'agvtool .

Essaye ça:

  1. Configurez-le comme décrit dans la documentation Apple liée ci-dessus.
  2. Ajouter un script comme pré-action au projet -> Modifier le schéma ... -> Archiver (ou autre si vous préférez)
  3. Définir: fournir les paramètres de construction à partir de <your_app_target>

Le script (la première ligne est facultative):

exec > ${PROJECT_DIR}/prebuild.log 2>&1
cd ${PROJECT_DIR}
xcrun agvtool next-version -all
cd -
goce
la source
0

Faisons cela à la manière d'Apple. Cela augmentera le nombre de build après chaque build réussi

Je vais vous guider à travers 5 images, parcourez-les.

  1. Sélectionnez 'Edit Scheme ...' dans la liste déroulante, lorsque vous sélectionnez le nom de votre projet situé à droite du bouton Stop_build_button. Vérifiez la première étape

  2. Dans le menu de gauche, développez l'option 'Construire' et sélectionnez 'Post-actions' Vérifiez la deuxième étape

  3. Ici, vous pouvez ajouter les codes (scripts) que vous souhaitez exécuter après la construction réussie de votre programme. C'est l'endroit où nous devons ajouter un peu de code pour que notre automatisation fonctionne parfaitement. >> 1. sélectionnez le bouton "ajouter (+)" dans le coin gauche pour ajouter un nouveau fichier de script >> 2. Maintenant, dans le menu déroulant, sélectionnez "Nouvelle action de script d'exécution" Vérifiez la troisième étape

  4. Il a 3 champs >> 1. shell est déjà assigné pour vous >> 2. maintenant pour «Fournir les paramètres de construction à partir de» Sélectionnez le nom de votre projet. >> 3. Theres un grand champ pour ajouter votre script, copiez et collez simplement ce code là: Vérifiez la quatrième étape

    PLIST = "$ {PROJECT_DIR} / $ {INFOPLIST_FILE}" PLB = / usr / libexec / PlistBuddy LAST_NUMBER = $ ($ PLB -c "Imprimer CFBundleVersion" "$ PLIST") NEW_VERSION = $ (($ LAST_NUMBER + 1)) $ PLB -c "Set: CFBundleVersion $ NEW_VERSION" "$ PLIST"

  5. Après avoir terminé la 4ème étape, sélectionnez simplement `` Fermer '' pour fermer la fenêtre et nous devons faire la dernière étape, accédez à votre fichier `` plist.info '' dans le menu Fichier du projet et assurez-vous que la clé `` Version du bundle '' sous la section `` Clé '' contient le plus a Vérification de la valeur numérique Cinquième étape

Debashish Das
la source