¿Mejor forma de incrementar el número de compilación?


133

He estado usando un script de shell como parte de mi proceso de compilación de Xcode para incrementar el número de compilación dentro del archivo plist , sin embargo, hace que Xcode 4.2.1 se bloquee con frecuencia (con un error sobre el objetivo que no pertenece a un proyecto; supongo El cambio del archivo plist confunde Xcode de alguna manera).

El script de shell hizo esto para que el número de compilación solo se incremente agvtoolcuando un archivo es más nuevo que el archivo plist (por lo que solo la construcción no incrementó el valor):

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

¿Hay alguna manera de incrementar el número de compilación (en el archivo plist o en cualquier otro lugar) que no rompa Xcode?

EDICIÓN FINAL : ahora hago este tipo de cosas usando un script de Python que acabo de hacer público en github . No está bien documentado, pero no debería ser difícil de resolver. Como beneficio adicional, este repositorio también contiene una secuencia de comandos útil para agrupar automáticamente la biblioteca de terceros en un paquete de aplicaciones.


1
Si alguien está interesado: modifiqué un poco el script para usar números hexadecimales en lugar de números decimales - gist.github.com/sascha/5398750
Sascha

1
Puede agregar este script como una acción previa a la compilación directamente, sin necesidad de invocar un script externo. No ejecute este script con una fase de compilación; Xcode solo copiará el plist actualizado cada otra compilación.
Ed McManus el

3
Fuera de la caja, recibí un error de "permiso denegado", así que pensé en señalar estas preguntas y respuestas a cualquier persona que experimente lo mismo: stackoverflow.com/q/9850936/519030
Jason

Este script falla con un código de salida 1. ¿Alguien puede ayudarme con esto?
Robert J. Clegg

@Tander Parece que no está proporcionando el archivo plist como argumento para el script.
trojanfoe

Respuestas:


29

Si entiendo su pregunta correctamente, ¿desea modificar el Project-Info.plistarchivo, que es parte de la plantilla de proyecto estándar de Xcode?

La razón por la que pregunto esto es que Project-Info.plistnormalmente está bajo control de versión, y modificarlo significa que se marcará como, bueno, modificado.

Si eso está bien con usted, entonces el siguiente fragmento actualizará el número de compilación y marcará el archivo como modificado en el proceso, donde get_build_numberhay algún script (es decir, un marcador de posición en este ejemplo) para obtener el número de compilación (posiblemente incrementado) que quiere usar:

#!/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 le permite configurar cualquier clave en un archivo plist, no solo el número de versión. Puede crear todos los archivos plist que desee e incluirlos en los recursos si es necesario. Luego se pueden leer desde el paquete.

En cuanto a su necesidad de mostrar la versión en el panel Acerca de y otros lugares, también puede consultar la configuración CFBundleGetInfoStringy CFBundleShortVersionString.


No necesito el git commit (o la etiqueta) en el archivo plist , por lo que un sistema de incremento simple está bien (como lo proporciona agvtool), sin embargo, el acto de modificar el plist durante la construcción rompe Xcode con frecuencia (ya que al eliminar el script no ha funcionado) se bloqueó una vez, cuando se bloqueaba cada 3 compilaciones más o menos). ¿Es posible poner la información de la versión en otro archivo plist y tenerla incluida con el paquete y accesible desde la aplicación?
trojanfoe

Excelente script: preferiría combinar esto con la sugerencia de Hugues BR de usarlo solo al archivar compilaciones. Mantiene los números bajos e ignora, sin embargo, muchas versiones de desarrollo se realizan entre versiones.
Jay

55
¿Qué es get_build_number? ¿Es eso solo un marcador de posición?
chrisp

Sí, get_build_numberes solo un marcador de posición: se actualizó la respuesta para aclarar.
Monolo

72

He jugado muchas de las respuestas a esta pregunta, y ninguna de ellas me satisfizo. Sin embargo, finalmente se me ocurrió una mezcla que realmente me gusta.

Hay dos pasos, uno al principio y otro al final de las fases de construcción.

Al principio:

# 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

Al final:

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

Al mirar Info.plist en Xcode, verá que el número de versión es "DESARROLLO", pero la aplicación desarrollada tendrá un número de compilación en constante aumento. (Siempre y cuando siempre hagas tus compilaciones desde la misma rama).

Establecer el número de versión nuevamente en una cadena constante al final evita que el archivo Info.plist se cambie al compilar la aplicación.

Por qué me gusta este método:

  • Fácil
  • No contamina el historial de versiones de Git
  • CFBundleVersion es totalmente automático
  • El bonito número de versión se puede modificar cuando quiera

Mantener los números de versión fuera del archivo plist controlado por versión es la mejor manera de hacerlo, especialmente si tiene un brach por lanzamiento y, a veces, necesita fusionar o elegir. ¡Gracias!
Matthew Phillips

14
Podrías usar en git rev-list --count HEADlugar de git rev-list HEAD | wc -l | tr -d ' '.
kennytm

Hmm Descubrí que si usas fastlanepara cargar compilaciones automáticas de esta manera, obtienes: ERROR ITMS-90058: "Este paquete no es válido. El valor de la clave CFBundleVersion [DESARROLLO] en el archivo Info.plist debe ser una lista separada por puntos de la mayoría de los tres enteros no negativos ".
fatuhoku

1
No estoy seguro exactamente a dónde debería ir, puse el primer script como la primera fase de compilación, y el último script como la última fase de compilación y funciona para mí.
Wil Gieseler

1
Definitivamente puede confirmar Info.plist usando esta solución, ese es el punto completo. Info.plist siempre se establece y se registra con el número de versión establecido en "DESARROLLO", se cambia temporalmente durante el proceso de compilación y luego se establece nuevamente en "DESARROLLO" para que Info.plist sea estable.
Wil Gieseler

38

He usado esta lista. Funciona como se esperaba. https://gist.github.com/sekati/3172554 (todo el crédito va al autor original)

Scripts que modifiqué con el tiempo.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Como estos aspectos esenciales están ayudando a la comunidad de desarrolladores, hice que el proyecto GitHub fuera de él. Así que desarrollémoslo bien. Aquí está el proyecto GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

He actualizado el código para ambas secuencias de comandos un poco de mejora. en lugar de usar a continuación, tome lo último de GitHub

Para la versión:

# 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}"

Para construir:

# 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}"

Esto siempre incrementará el número de compilación, donde, como quería, solo aumentaría si un archivo fuente cambia. Es solo el script que utilizo actualmente con menos controles de seguridad y es menos exigente con lo que ha cambiado.
trojanfoe

XCode 5: Editor (barra de menú) → Agregar fase de compilación → Agregar archivos de copia Fase de compilación:
Jonny

@trojanfoe: puede ejecutar este script como enlace post commit. Este escenario solo aumentará el número de compilación cuando confirmes tu código para repositorio. La respuesta a continuación de LostInTheTrees es algo más que quizás quieras hacer.
Alix

Los scripts de shell vinculados por @Alix ahora son bastante diferentes a los publicados aquí. Para incrementar el número de compilación solo al hacer una compilación de archivo, puede usar una esencia que he hecho, muy basada en los scripts anteriores de Alix, aquí: gist.github.com/mattpotts/abcffea6d08ad45739ef
Matthew

14

Toda esta entrada fue extremadamente útil. Utilicé este truco pero configuré mi script como un enlace posterior a la confirmación en GIT, por lo que CFBundleVersion se incrementa después de cada confirmación exitosa. El script de gancho va en .git / hooks. Se deja un registro en el directorio del proyecto.

Esto cumple con mi criterio más básico. Quiero poder extraer una versión de GIT y reconstruir la compilación exacta que tenía anteriormente. Cualquier incremento realizado durante el proceso de compilación no hace esto.

Aquí está mi guión:

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

Tengo el mismo requisito, por lo que el número de compilación solo se incrementa si se ha modificado un archivo fuente. He encontrado que esto funciona muy bien y no he tenido que hacer cambios en el bump_build_number.shscript desde su creación.
trojanfoe

14

No sé cuál es la mejor, pero publicaré la respuesta de Apple en caso de que alguien la esté buscando ...

De acuerdo con esta publicación de preguntas y respuestas de Apple :

Automatización de versiones y números de compilación utilizando agvtool

Las teclas de versión y número de compilación especifican respectivamente las versiones de marketing e internas de su aplicación. agvtool es una herramienta de línea de comandos que le permite incrementar automáticamente estos números al siguiente número más alto o a un número específico.

El número de compilación identifica una versión inédita o lanzada de su aplicación. Se almacena en la lista de información de su aplicación comoCFBundleVersion (versión de paquete).

Debe completar los siguientes pasos en su proyecto Xcode:

  1. Habilitar agvtool

Navegue hasta el panel Configuración de compilación de su destino, luego actualícelo para todas sus configuraciones de compilación de la siguiente manera:

  • Establezca la Versión del proyecto actual en el valor que elija.

Su archivo de datos del proyecto Xcode, project.pbxproj, incluye una CURRENT_PROJECT_VERSIONconfiguración de compilación (Versión actual del proyecto), que especifica la versión actual de su proyecto. agvtool busca project.pbxproj para CURRENT_PROJECT_VERSION. Continúa ejecutándose si CURRENT_PROJECT_VERSIONexiste y deja de ejecutarse, de lo contrario. Su valor se utiliza para actualizar el número de compilación.

  • Establezca el Sistema de versiones en Apple Generic.

Por defecto, Xcode no utiliza ningún sistema de versiones. Establecer el sistema de control de versiones en Apple Generic garantiza que Xcode incluirá toda la información de versión generada por agvtool en su proyecto.

Establecer el sistema de versiones a Apple Generic

  1. Configure su versión y números de compilación

agvtool busca en la lista Info.plist de su aplicación su versión y números de compilación. Los actualiza si existen y no hace nada, de lo contrario. Asegúrese de que las teclas CFBundleVersion(Versión de paquete) y CFBundleShortVersionString(Cadena de versiones de paquete, abreviadas) existan en su Lista de información como se ve en la imagen a continuación:

Configure su versión y números de compilación

Salga de Xcode, luego navegue al directorio que contiene su archivo de proyecto .xcodeproj en la aplicación Terminal antes de ejecutar cualquiera de los siguientes comandos. El archivo de proyecto .xcodeproj contiene project.pbxproj, que es utilizado por agvtool. (Esta es la parte que puede ejecutar en un script en lugar de la línea de comando).

Actualización del número de versión

Para actualizar el número de versión a una versión específica, ejecute

xcrun agvtool new-marketing-version <your_specific_version>

Ejemplo: actualice el número de versión a 2.0

xcrun agvtool new-marketing-version 2.0

Actualización del número de compilación

Para incrementar automáticamente su número de compilación, ejecute

xcrun agvtool next-version -all

Para establecer el número de compilación de su aplicación en una versión específica, ejecute

xcrun agvtool new-version -all <your_specific_version>

Ejemplo: establezca el número de compilación en 2.6.9

xcrun agvtool new-version -all 2.6.9

Prima:

Para ver el número de versión actual, ejecute

xcrun agvtool what-marketing-version

Para ver el número de compilación actual, ejecute

xcrun agvtool what-version

77
El problema con este es que agvtool anulará la compilación de xcode, por lo que no puede integrarse como un script en las fases de compilación.
Daniel Schlaug

1
¿No podría simplemente poner protuberancia a través de agvtool en las acciones previas de compilación del esquema?
lottadot

11

FWIW: esto es lo que estoy usando actualmente para aumentar el número de compilación solo para las versiones de lanzamiento (que incluye el archivado). Funciona bien bajo Xcode 5.1.

Simplemente copie / pegue el fragmento en una fase de compilación del script de ejecución directamente en 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;

¿Cómo puedes incrementar CFBundleVersion? ¿En Xcode 5.1 es una cadena formateada como "1.0"?
chrisp

1
Finalmente, alguien lo hace bien :) ¿Por qué me importaría cada compilación que ejecuto en mi dispositivo de desarrollo? Las versiones (y las versiones para los probadores) cuentan, no las compilaciones "hmm, mueve ese 2px a la izquierda".
uvesten

7

Gracias por el guion. Funciona muy bien

Mi Info.plist está en un subdirectorio con un nombre que contiene espacios, así que tuve que modificar el script de ejecución con comillas alrededor de la ruta de plist:

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

y el script de shell de la misma manera con comillas alrededor de todas las rutas:

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

Sí, eso tiene sentido. Me alegra que lo encuentres útil; He estado usando desde entonces sin ningún problema bajo Xcode 4. {2,3,4,5}.
trojanfoe

¡Me hubiera ahorrado unas horas si hubiera visto esta respuesta! Además, tenga en cuenta que el número de compilación no debe tener un decimal, o BASH se torcerá.
Brenden

6

El guión que estoy usando actualmente está muy basado en Alix , arriba. Mi adaptación, a continuación, agrega una verificación para hacer solo el incremento automático en una versión / archivo de compilación.

Sin ese cambio, habrá conflictos de control de versión ya que cada desarrollador incrementará el número de compilación a su propio ritmo. Y el hecho de que el historial de git se contaminaría innecesariamente con el número de compilación cambiando todo el tiempo.

# 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}"

También está disponible (en un formato un poco más fácil de copiar y pegar) como una esencia de GitHub .


5

Recomendaría el uso de autorrevisión .

Xcode permite un archivo de encabezado (que se puede generar automáticamente en el momento de la compilación y no en las vcs) para proporcionar valores que se expandirán en info.plist en el momento de la compilación. Puede encontrar un tutorial para configurar esto en el sitio web de revisión automática .

La revisión automática tiene un tipo de salida orientado a estos tipos de archivos de encabezado para ayudar exactamente en estas situaciones.


1
Autorevisionno parece topar un número de compilación, como se requiere?
trojanfoe

Suponiendo que uno solo se basa en una nueva confirmación, entonces VCS_NUMdebería ser lo que está buscando ( vea autorevision.hun ejemplo ).
dak180

Vienna-Info.plist y Vienna-All.xcconfig son un buen ejemplo de cómo se puede configurar esto en cualquier proyecto de xcode.
dak180

4

Un problema con algunas de estas soluciones es que Launch Services solo reconoce cuatro cinco dígitos principales en la versión de paquete . Tengo un proyecto con un número de compilación que está en los miles, por lo que quería usar algunos de los dígitos menos significativos.

Este script de Perl incrementa todos los Info.plists en el proyecto, no solo el del objetivo actual, por lo que todos los números de compilación permanecen en el bloque. También usa un dígito de parche y dos dígitos menores, por lo que la compilación 1234 recibe la versión 1.23.4. Lo uso como un comportamiento previo a la compilación, por lo que se aplica a todos los proyectos que construyo.

El guión es bastante fuerza bruta, pero funciona para mí.

#!/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');
}

La publicación que está citando indica que ' Efectivamente, LS espera el siguiente formato: nnnnn [.nn [.nn]] [X] donde n es un dígito 0-9, los corchetes indican componentes opcionales, y X es cualquier cadena que no comenzando con un dígito. X se ignora cuando está presente. '- así que eso es 99999 compilaciones. ¿Debería ser suficiente para la mayoría de los proyectos ...?
Jay

@ Jay Aparentemente interpreté mal eso como cuatro dígitos. Ups (Aún así, si su estilo de desarrollo implica muchos ajustes y reconstrucción, no es inconcebible que pueda alcanzar 100,000 construcciones después de años de desarrollo en un proyecto.)
Brent Royal-Gordon

@ BrentRoyal-Gordon Verdadero: modifiqué mi script de compilación para incrementar las compilaciones solo para configuraciones de lanzamiento ... aunque probablemente nunca haya llegado a cerca de 10k compilaciones, incluso con mi producto heredado de más de 10 años, se siente bien tener mucho espacio para la cabeza con nuevos proyectos de Cacao ;-)
Jay

4

Podrías usar las versiones genéricas de Apple . Básicamente, todo lo que tiene que hacer es llamar agvtool next-version -alldesde el directorio que aloja su archivo .xcproj. Para obtener más detalles, consulte la url anterior.


3
El problema con esta solución es que llamar a agvtool desde un script en el proyecto cancelará su compilación. No es una buena solución a menos que pueda encontrar una solución para esto.
Dan Loewenherz

3

Sobre la base de la solución de Wil Gieseler , solo tenía un cambio que quería hacer. Su solución pone el recuento de git commits en el número de compilación. Útil, pero sigue siendo un poco difícil encontrar la confirmación real que creó esa compilación. No me importaba demasiado si el número de compilación aumentaba monotónicamente, por lo que eliminé ese requisito para poder acceder más fácilmente a la confirmación que generó un binario dado.

Con ese fin, modifiqué su primer script a lo siguiente:

# 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>"

Esto convierte la versión corta del git SHA actual en decimal. Los caracteres hexadecimales no funcionan bien con los requisitos de número de compilación de Apple, por lo que tuve que hacer esto. Para volver a convertirlo, simplemente ejecuta algo como esto:

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

en bash, ¿dónde <build number>está el número de compilación que obtuviste de un binario? Luego, solo corre git checkout $SHAy listo.

Como se trata de una adaptación de la solución de Wil Gieseler , como se mencionó anteriormente, también necesitará el siguiente script posterior a la compilación:

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

que mantiene limpio tu historial de git.


Entonces, ¿cómo funciona eso, dado que vas a escribir la información de git en la Info.plistque git rastrea?
trojanfoe

@trojanfoe Como mencioné en la parte superior de la respuesta, esta respuesta es una adaptación de la solución de Wil Gieseler. Como tal, requiere la misma secuencia de comandos posterior a la compilación utilizada allí. He agregado eso a la respuesta explícitamente.
ravron

2

Intenté el procedimiento modificado y no funcionó porque: -

  1. Xcode 4.2.1 cambia el subdirectorio xcuserdata en .xcodeproj

  2. git observa el cambio anterior en Project-Info.plist

La siguiente modificación hace que se ignoren y solo marca cambios genuinos: -

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

2

Es posible que desee hacer esto solo cuando archiva (y carga a TF, por ejemplo). De lo contrario, su número de versión podría subir muy rápido.

En el esquema (Producto / Editar esquema / Archivar / Pre-acciones) puede agregar un script que se ejecutará solo cuando archiva.

Además, es posible que desee restablecer el número de compilación cada vez que incremente la versión de la aplicación.

Lo último, si usa el archivo en su lugar, puede deshabilitar de forma segura:

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

Como el número de compilación se incrementará solo cuando archives ...

EDITAR: corrija lo que dije, las acciones previas en el archivo ocurren después de la compilación (pero antes del archivo), por lo que el número de compilación se incrementará para el próximo archivo ... Pero puede crear un nuevo esquema y agregar esta acción en la compilación (pre acciones) de este nuevo esquema. y usa este esquema cuando quieras crear una nueva compilación


1
Sí, está subiendo rápidamente (más de 5500 en este momento), pero eso no es un problema para mí; Es solo un número. Es interesante cuántas veces Cmd-B / Cmd-R recibe un golpe antes de que algo funcione ...
trojanfoe

2

Yo uso la última revisión SVN para el número de compilación. Si cambia Info.plist en el directorio de compilación, no afectará la fuente 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

Siento que he encontrado a mi tribu. Tribu, espero que VersionX te divierta.

Hace una década, mientras trabajaba en un espacio de trabajo que tenía más de 25 proyectos de Xcode, aproveché la oportunidad para automatizar la versión y crear actualizaciones de cadenas en un grado que podría parecer absurdo, si solo mantiene uno o dos proyectos con actualizaciones ocasionales.

VersionX:

  • conoce el tipo de compilación (Release / Debug)
  • recopila información en el momento de la compilación desde el repositorio (se incluye soporte de git, pero se puede personalizar para hg, svn o lo que sea que use)
  • proporcionó cadenas de versiones de marketing sofisticadas y fácilmente personalizables (que tenían mucha más variación antes de que la App Store impusiera una convención) para que pudiera incrementar automáticamente las cadenas que incluían símbolos para una "beta" usando una convención de etiqueta git, por ejemplo.
  • incluye una clase poblada con variables de instancia que contienen información de versión y confirmación. Esto es útil para completar el panel Acerca de y construir cadenas de registro, informes de fallos o informes de errores de correo electrónico del usuario con información previamente rellenada.

Fue divertido hacerlo. Aprendí mucho sobre el sistema de construcción Xcode.

Aquí hay un ejemplo del tipo de versión elegante y cadenas de compilación que VersionX podría generar automáticamente.

VersiónX 1.0.1 β7 (c5959a3 "Limpio")

Versión de marketing: VersiónX 1.0.1 β7 El "1.0.1 se deriva de la etiqueta para la confirmación, mientras que la" Beta 7 "se genera automáticamente por el recuento de confirmación o el recuento de compilación (por ejemplo).

Versión de compilación: (c5959a3 "Limpio") Muestra el hash de confirmación breve y le informa que el directorio de compilación no tuvo cambios no confirmados.

VersionX (fuente en GitHub): un sistema barroco para incrementar automáticamente la versión y crear cadenas en proyectos de Xcode.

La documentación de VersionX.


1

Es posible que desee ver una nueva herramienta que he estado desarrollando llamada Xcodebump. Puede manejar la actualización de CFBundleShortVersionString y CFBundleVersion. Como paso final, también registrará git y etiquetará el commit para que coincida con esos valores de CFBundle.

El proyecto Xcodebump se encuentra aquí:

https://github.com/markeissler/Xcodebump


1

Actualizo build numbersiguiendo el método.

$INFO_FILEes la ruta del archivo plist. Y $build_numberes un nuevo número de compilación para este edificio.

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

En general, my $build_numberestá compuesto por majory minorpartes. El minorproviene de la información del proyecto. Así que describo cómo generar la majorparte.

## 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}"

Tengo 2 estrategias para decidir el $build_number .

Primera estrategia

Esta estrategia utiliza el git tagrecuento para decidir el majorde build number. Si hay 53etiquetas del proyecto, regresará 53siguiendo el script de shell.

En general, está aumentando. Y obligará al desarrollador a poner una etiqueta git antes de publicar.

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

Segunda estrategia

Deje que el sistema Jenkins CI decida la majorparte. Tiene una variable de entorno BUILD_NUMBER. Está aumentando automáticamente cuando se construye en el sistema CI. Esta información es útil para rastrear el historial del proyecto en el sistema CI.

major_number=${BUILD_NUMBER}

1

Heres una versión actualizada. Esto funciona a partir de Xcode 9.3.1, iOS 11.

Haga clic en 'Crear fases' desde el objetivo de su aplicación, haga clic en el icono + para agregar un nuevo script de ejecución y, en el cuadro, pegue este código.

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

Vaya al archivo Info.plist y configure la 'Versión del paquete' en 1, y la 'Cadena de versiones del paquete, corta' en 1, debe estar configurado.

Cree el proyecto con Info.plist a la vista, y debería ver el cambio de la versión del paquete (número de compilación).

  • Tenga en cuenta que a partir de Xcode 9.3.1, no podrá ver estos cambios desde la pestaña general, pero verá los cambios cuando archive una compilación y en Info.plist

0

Aquí está mi solución. Si eres como yo: terminal amigable, como rubí, como versiones semánticas, prueba esto.

Haga un archivo llamado Rakefileque contenga esto:

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
}

Preparar: gem install xcodeproj versionomy

Ejecutar: rake increment:majoro rake increment:minoro rake increment:tinysiempre que lo desee.


0

Me resulta más conveniente utilizar la versión de automatización y los números de compilación utilizando agvtool .

Prueba esto:

  1. Configúrelo como se describe en la documentación de Apple vinculada anteriormente.
  2. Agregue script como Pre-acción al Proyecto -> Editar esquema ... -> Archivar (u otro si lo prefiere)
  3. Establecer: Proporcionar configuraciones de compilación de <your_app_target>

El script (la primera línea es opcional):

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

0

Hagamos esto a la manera de Apple. Aumentará el número de compilación después de cada compilación exitosa

Te guiaré a través de 5 imágenes, solo hazlo.

  1. Seleccione 'Editar esquema ...' en el menú desplegable, cuando seleccione el nombre de su proyecto ubicado en el lado derecho del botón Stop_build_button. Verificar primer paso

  2. Desde el menú lateral izquierdo, expanda la opción 'Construir' y seleccione 'Acciones posteriores' Verifique el segundo paso

  3. Aquí puede agregar sus códigos deseados (scripts) que desea ejecutar después de la compilación exitosa de su programa. Es el lugar donde tenemos que agregar una pequeña cantidad de código para que nuestra automatización funcione perfectamente. >> 1. seleccione el botón 'agregar (+)' de la esquina lateral izquierda para agregar un nuevo archivo de secuencia de comandos >> 2. Ahora, desde el menú desplegable, seleccione 'Nueva acción de ejecución de secuencia de comandos' Verifique el tercer paso

  4. Tiene 3 campos >> 1. Shell ya está asignado para usted >> 2. ahora para 'Proporcionar configuraciones de compilación desde' Seleccione su nombre de proyecto. >> 3. Hay un gran campo para agregar su secuencia de comandos, simplemente copie y pegue este código allí: Marque el cuarto paso

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

  5. Después de completar el cuarto paso, simplemente seleccione 'Cerrar' para cerrar la ventana y tenemos que hacer el último paso, vaya a su archivo 'plist.info' en el menú Archivo de proyecto y asegúrese de que la clave 'Versión de paquete' en la sección 'Clave' contenga más un control numérico del quinto paso

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.