web-dev-qa-db-fra.com

Meilleure façon d’augmenter le numéro de build?

J'utilise un script Shell dans le cadre de mon processus de compilation Xcode pour incrémenter le numéro de build dans le fichier plist, mais cela provoque un crash fréquent de Xcode 4.2.1 (avec une erreur concernant la cible n'appartenant à aucun projet; je suppose que la modification du fichier plist confond quelque peu Xcode).

Le script Shell a agi de la sorte pour que le numéro de version ne soit incrémenté que de agvtool lorsqu'un fichier est plus récent que le fichier plist (ainsi, la construction ne incrémente pas 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) sans casser Xcode?

EDIT: Voici ma solution finale, basée sur la suggestion de @Monolo. J'ai créé le script suivant dans ${PROJECT_DIR}/tools (frère du répertoire .xcodeproj):

#!/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

EDIT 2: J'ai modifié le script pour incorporer la suggestion de @Milliways.

J'ai ensuite appelé le script à partir de la section 'Build Phases' de la cible Xcode: Xcode build phases screenshot

EDIT 3: Selon la réponse de @ massimobio, vous devrez ajouter des guillemets autour de l'argument Plist s'il contient des espaces.

EDIT 4: Juste pour indiquer que ma méthode préférée pour invoquer ce script de génération consiste maintenant à créer une cible distincte et à rendre la cible de l'application dépendante de cette cible numéro de composition en bloc. Cela garantit qu'il est appelé avant que la cible de l'application ne rien avec le plist (j'ai remarqué qu'elle aime traiter le plist au début de la construction). J'ai également opté pour une solution purement python qui conserve le numéro de version dans un fichier séparé et écrit les fichiers source de la version, ce qui est plus utile pour les produits multiplates-formes (c’est-à-dire que Visual Studio sous Windows peut invoquer le script et évidemment, les constructions de type cmake/make peuvent le faire aussi). Cela présente l'avantage que le numéro de version est toujours le même, même sous différentes plates-formes, et qu'il est également possible de mettre à jour le fichier Visual Studio Resource.rc avec la version/construction actuelle.

Here est le script python que j'utilise actuellement pour mettre à jour les fichiers Info.plist dans le projet Xcode.

xcodeshellversionxcrunagvtool
132
trojanfoe

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

La raison pour laquelle je pose cette question est que Project-Info.plist est normalement sous contrôle de version, et sa modification signifie qu'il sera marqué comme étant, ainsi, modifié. 

Si cela vous convient, l'extrait suivant met à jour le numéro de build et marque le fichier comme modifié dans le processus, où get_build_number est un script (c'est-à-dire un espace réservé dans cet exemple) pour obtenir le numéro de construction (é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 que vous voulez et les inclure dans les ressources si nécessaire. Ils peuvent ensuite être lus à partir du paquet.

Pour ce qui est de votre besoin d’afficher la version dans le volet À propos de et dans d’autres emplacements, vous pouvez également examiner le paramétrage de CFBundleGetInfoString et CFBundleShortVersionString.

29
Monolo

J'ai malmené beaucoup de réponses à cette question, et aucune d'entre elles ne m'a 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
buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

À la fin:

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

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

Définir le numéro de version sur une chaîne constante à la fin empêche le fichier Info.plist d'être modifié par la construction de 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é à tout moment
68
Wil Gieseler

J'ai utilisé cette glist sa génial et fonctionne comme prévu. https://Gist.github.com/sekati/3172554 (tout le crédit revient à l'auteur original)

Sctipts que j'ai modifié au fil du temps.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

En tant que ces Gist aident la communauté de développement. Je pensais en faire 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 d'amélioration. au lieu d’utiliser ci-dessous, prenez le dernier de 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 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)

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}"
37
Alix

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, de sorte que CFBundleVersion est incrémenté après chaque commit réussi. 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 fondamental. Je veux pouvoir extraire une version de GIT et reconstruire la version exacte que j'avais précédemment. Toute incrémentation effectuée 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
14
LostInTheTrees

Je ne sais pas quelle est la meilleure solution, mais je publierai la réponse d'Apple au cas où quelqu'un la chercherait ...

D'après ce message de questions-réponses d'Apple :

Automatisation des numéros de version et de construction à l'aide d'agvtool

Les clés de version et de build spécifient respectivement les versions marketing et internes de votre application. agvtool est un outil de ligne de commande qui vous permet d'incrémenter automatiquement ces nombres au nombre immédiatement supérieur ou à un nombre spécifique.

Le numéro de version identifie une version non publiée ou publiée de votre application. Il est stocké dans l’Info.plist de votre application sous la forme CFBundleVersion (version Bundle). 

Vous devez suivre 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.

Votre fichier de données de projet Xcode, project.pbxproj, inclut un paramètre de construction CURRENT_PROJECT_VERSION (version actuelle du projet), qui spécifie la version actuelle de votre projet. agvtool recherche project.pbxproj pour CURRENT_PROJECT_VERSION. Il continue à fonctionner si CURRENT_PROJECT_VERSION existe et cesse de fonctionner, 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 gestion de versions. La configuration 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.

Set Versioning System to Apple Generic

  1. Configurez votre version et construisez des numéros

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

Set up your version and build numbers

Quittez Xcode, puis naviguez jusqu'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, utilisé par agvtool. (C'est la partie que vous pouvez exécuter dans un script au lieu d'une 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: Met à jour le numéro de version vers 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 build actuel, exécutez

xcrun agvtool what-version
14
FormigaNinja

FWIW - C’est ce que j’utilise actuellement pour augmenter le numéro de compilation uniquement pour les versions de version (qui inclut l’archivage). Fonctionne bien sous Xcode 5.1.

Copiez/collez simplement l'extrait de code dans une phase de construction Exécuter le script 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;
11
Jay

Le script que j'utilise actuellement est très basé sur Alix's , ci-dessus. Mon adaptation, ci-dessous, ajoute un contrôle pour ne faire que l'incrémentation automatique sur une version release/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 git serait inutilement pollué avec le numéro de build qui change 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) en tant que GitHub Gist .

6
Matthew

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 script d'exécution avec des guillemets autour du chemin de la pliste:

${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
6
massimobio

Je recommanderais l'utilisation de 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) de fournir des valeurs qui seront développées dans le fichier info.plist au moment de la construction. Vous pouvez trouver une procédure pour l’installer sur le site Web autorevision .

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

5
dak180

Un problème avec certaines de ces solutions est que Launch Services ne reconnaît que quatre cinq chiffres principaux dans la version groupée . J'ai un projet avec un numéro de construction qui se compte en milliers, alors je voulais utiliser certains des chiffres les moins significatifs.

Ce script Perl incrémente tous les Info.plists du projet, et pas seulement celui de la cible actuelle, de sorte que les numéros de build restent en bloc. Il utilise également un chiffre de patch et deux chiffres mineurs. La version 1.34.4 est donc fournie à la version 1.23.4. Je l'utilise comme un comportement de pré-génération, donc cela 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');
}
4
Brent Royal-Gordon

Vous pouvez utiliser le versioning générique d’Apple . Tout ce que vous avez à faire, c'est d'appeler agvtool next-version -all à partir du répertoire qui héberge votre fichier .xcproj. Pour plus de détails, consultez l'URL ci-dessus.

4
Valentin Radu

En me basant sur la solution de Wil Gieseler , je n’avais qu’un changement à faire. 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 qui a créé cette construction. Peu m'importait que le nombre de build augmente de façon monotone, j'ai donc abandonné cette exigence pour pouvoir accéder plus facilement au commit qui a généré 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>"

Ceci convertit la version courte du git actuel SHA en décimal. Les caractères hexadécimaux ne répondent pas bien aux exigences du numéro de build d’Apple, c’est pourquoi j’ai dû le faire. Pour le reconvertir, vous exécuteriez simplement quelque chose comme ceci:

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

in bash, où <build number> est le numéro de construction obtenu à partir d'un binaire. Ensuite, lancez simplement git checkout $SHA, et voilà.

S'agissant d'une adaptation de de la solution de Wil Gieseler , comme mentionné ci-dessus, vous aurez également besoin du script post-génération suivant:

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

qui garde votre histoire git propre.

3
ravron

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

Il y a dix ans, alors que je travaillais sur un espace de travail contenant plus de 25 projets Xcode, j'en ai profité pour automatiser la version et créer des mises à jour de chaînes à un degré qui peut sembler absurde, si vous ne gérez qu'un projet ou deux 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 (le support git est inclus, mais peut être personnalisé pour hg, svn ou tout ce que vous utilisez)
  • prévu pour des chaînes de version marketing facilement personnalisables (qui comportaient beaucoup plus de variations avant que l'App Store n'impose une convention) afin que vous puissiez incrémenter automatiquement des chaînes contenant des symboles pour une "version bêta" à l'aide d'une convention de balise git, par exemple.
  • inclut une classe remplie de variables d'instance contenant les informations de version et de validation. Ceci est utile pour renseigner votre panneau et pour construire des chaînes de journalisation, des rapports de plantage ou des rapports de bogue de messagerie électronique avec des informations préremplies. 

C'était amusant à faire. J'ai appris un tas de bateaux sur le système de construction Xcode.

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

VersionX 1.0.1 β7 (c5959a3 “Nettoyer”)

Version marketing: VersionX 1.0.1 β7 Le "1.0.1 est dérivé de la balise pour la validation, tandis que La" Bêta 7 "est automatiquement générée par le nombre de validations, ou le nombre de constructions ( par exemple).

Version de construction: (c5959a3 «Nettoyer») Affiche le hachage de validation court et vous informe que le répertoire de construction ne contient 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 de VersionX.

2
Gary W. Longsine

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

Dans le schéma (Product/Edit Scheme/Archive/Pre-Actions), vous pouvez ajouter un script à exécuter uniquement 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 les archives, 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 archive ...

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

2
Hugues BR

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 entraîne leur ignorance et ne marque que les modifications authentiques: -

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

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 source Info.plist:

# 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}'`
2
jack

Je met à jour build number en suivant la méthode.

$INFO_FILE est le chemin du fichier plist . Et $build_number est un nouveau numéro de build pour ce bâtiment. 

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

En règle générale, mon $build_number est composé de major et minor parties . La minor provient d'informations de projet. Je décris donc comment générer la partie major.

## 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 nombre git tag pour décider de la major de build number. S'il existe des balises 53 du projet, il renverra 53 en suivant le script Shell.

Généralement, cela augmente. Et cela obligera le développeur à mettre une balise git avant 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 partie major. Il a une variable d'environnement BUILD_NUMBER. Il augmente automatiquement lorsque vous utilisez le système CI. Ces informations sont utiles pour suivre l'historique du projet sur le système CI.

major_number=${BUILD_NUMBER}
1
AechoLiu

Vous voudrez peut-être consulter un nouvel outil que j'ai développé, appelé Xcodebump. Il peut gérer la mise à jour à la fois CFBundleShortVersionString et CFBundleVersion. La dernière étape consiste également à vérifier et à baliser le commit afin qu'il corresponde aux valeurs de CFBundle.

Le projet Xcodebump se trouve ici:

https://github.com/markeissler/Xcodebump

1
markeissler

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

Cliquez sur 'Construire les phases' à partir de votre cible d'application, cliquez sur l'icône + pour ajouter un nouveau script d'exécution, puis collez ce code dans la zone.

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 réglez la «Version du paquet» sur 1, et la «Chaîne des versions du paquet, courte» sur 1, vous devriez être défini.

Générez le projet avec Info.plist dans la vue. La version de l’ensemble (numéro de version) devrait être modifiée.

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

Je trouve très pratique d’utiliser Automatiser les numéros de version et de construction à l’aide de agvtool .

Essaye ça:

  1. Configurez-le comme décrit dans la documentation Apple ci-dessus.
  2. Ajouter script en tant que pré-action dans Projet -> Éditer le schéma ... -> Archiver (ou autre si vous préférez)
  3. Set: Fournit 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 -
0
goce

Voici ma solution ... Si vous êtes comme moi: terminal friendly, comme Ruby, comme les versions sémantiques, essayez ceci.

Créez un fichier nommé Rakefile qui 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éparez: gem install xcodeproj versionomy

Exécuter: rake increment:major ou rake increment:minor ou rake increment:tiny quand vous le souhaitez.

0
mash