Лучший способ увеличить номер сборки?

Я использовал сценарий оболочки как часть моего процесса сборки XCode, чтобы увеличить номер сборки в файле plist, однако это часто приводит к сбою XCode 4.2.1 (с ошибкой о том, что цель не принадлежит проекту; я предполагаю, изменение файла plist каким-то образом сбивает с толку Xcode).

Сценарий оболочки сделал это так, что номер сборки увеличивается только на agvtool когда файл новее, чем файл plist (поэтому простое построение не увеличило значение):

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

Есть ли способ увеличить номер сборки (в файле plist или где-либо еще), который не нарушает Xcode?

РЕДАКТИРОВАТЬ: Вот мое окончательное решение, основанное на предложении @Monolo. Я создал следующий скрипт в ${PROJECT_DIR}/tools (брат к .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

РЕДАКТИРОВАТЬ 2: я изменил сценарий, чтобы включить предложение @Milliways.

Затем я вызвал скрипт из раздела "Фазы сборки" цели Xcode: Скриншот фаз сборки Xcode

РЕДАКТИРОВАТЬ 3: Согласно ответу @massimobio, вам нужно добавить кавычки вокруг аргумента plist, если он содержит пробелы.

РЕДАКТИРОВАТЬ 4: Просто чтобы обновить, что мой предпочтительный метод вызова этого сценария сборки - теперь создать отдельную цель и сделать цель приложения зависимой от этой цели Bump Build Number. Это гарантирует, что он вызывается до того, как цель приложения сделает что-либо с plist (я заметил, что ему нравится обрабатывать plist в начале сборки). Я также переключился на чисто Python-решение, которое хранит номер версии в отдельном файле и записывает исходные файлы версии, поскольку это более полезно для кросс-платформенных продуктов (т. Е. Visual Studio под Windows может вызывать сценарий, и очевидно, сборки cmake/make-type тоже могут это делать). Преимущество заключается в том, что номер сборки всегда одинаков даже для разных платформ, а также возможно обновление Visual Studio. Resource.rc файл с текущей версией / сборкой.

Вот скрипт Python, который я сейчас использую для обновления Info.plist файлы в проекте Xcode.

Источник

20 ответов

Решение

Если я правильно понимаю ваш вопрос, вы хотите изменить Project-Info.plist файл, который является частью стандартного шаблона проекта XCode?

Я спрашиваю это потому, что Project-Info.plist обычно находится под контролем версий, и его изменение означает, что он будет помечен как хорошо измененный.

Если это вас устраивает, то следующий фрагмент обновит номер сборки и пометит файл как измененный в процессе, где get_build_number это некоторый скрипт (то есть заполнитель в этом примере) для получения (возможно увеличенного) номера сборки, который вы хотите использовать:

#!/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 позволяет вам установить любой ключ в файле plist, а не только номер версии. Вы можете создать все необходимые файлы plist и при необходимости включить их в ресурсы. Затем их можно прочитать из комплекта.

Что касается вашей необходимости показать версию в панели about и других местах, вы также можете посмотреть в настройках CFBundleGetInfoString а также CFBundleShortVersionString,

Источник

Я возился с множеством ответов на этот вопрос, и ни один из них меня не удовлетворил. Однако я наконец-то придумала смесь, которая мне действительно нравится!

Есть два шага: один в начале и один в конце фаз сборки.

В начале:

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

В конце:

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

Глядя на Info.plist в XCode, вы увидите, что номер версии - "РАЗРАБОТКА", но сборка приложения будет постоянно увеличиваться. (Пока вы всегда делаете свои сборки из одной и той же ветки.)

Установка номера версии обратно в константную строку в конце предотвращает изменение файла Info.plist при сборке приложения.

Почему мне нравится этот метод:

  • Легко
  • Не загрязняет историю версий Git
  • CFBundleVersion полностью автоматический
  • Красивый номер версии может быть изменен всякий раз, когда я хочу
Источник

Я использовал этот список, он потрясающий и работает, как и ожидалось. https://gist.github.com/sekati/3172554 (все права принадлежат первоначальному автору)

Sctipts, которые я изменил с течением времени.

xcode-versionString-generator.sh,

xcode-build-number-generator.sh

Как эти суть помогают сообществу разработчиков. Я думал сделать проект GitHub из этого. Так что давайте развивать это хорошо. Вот проект GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Я обновил код для обоих скриптов, немного улучшив. вместо того, чтобы использовать ниже захватить последнюю из GitHub

Для версии:

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

Для сборки:

# 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}"
Источник

Я не знаю, какой путь самый лучший, но я опубликую ответ Apple на тот случай, если кто-то его ищет...

Согласно этому сообщению от Apple:

Автоматизация номеров версий и сборок с помощью agvtool

Клавиши номера версии и сборки соответственно определяют маркетинговую и внутреннюю версии вашего приложения. agvtool - это инструмент командной строки, который позволяет автоматически увеличивать эти числа до следующего наибольшего числа или до определенного числа.

Номер сборки идентифицирует неизданную или выпущенную версию вашего приложения. Он хранится в Info.plist вашего приложения как CFBundleVersion(Пакетная версия).

Вы должны выполнить следующие шаги в вашем проекте XCode:

  1. Включить agvtool

Перейдите на панель "Настройки сборки" своей цели, затем обновите ее для всех ваших конфигураций сборки следующим образом:

  • Установите текущую версию проекта на значение по вашему выбору.

Ваш файл данных проекта Xcode, project.pbxproj, содержит CURRENT_PROJECT_VERSION (Текущая версия проекта) параметр сборки, который указывает текущую версию вашего проекта. agvtool ищет файл project.pbxproj для CURRENT_PROJECT_VERSION, Он продолжает работать, если CURRENT_PROJECT_VERSION существует и перестает работать, в противном случае. Его значение используется для обновления номера сборки.

  • Установите систему управления версиями на Apple Generic.

По умолчанию Xcode не использует какую-либо систему управления версиями. Установка системы управления версиями в Apple Generic гарантирует, что Xcode будет включать всю информацию о версиях, созданных agvtool, в ваш проект.

Установите систему управления версиями на Apple Generic

  1. Настройте свою версию и номера сборки

agvtool ищет в Info.plist вашего приложения ваши версии и номера сборки. Он обновляет их, если они существуют, и ничего не делает, в противном случае. Убедитесь, что CFBundleVersion (Bundle версия) и CFBundleShortVersionString (Bundle versionstring, short) ключи существуют в вашем Info.plist, как показано на рисунке ниже:

Настройте свою версию и номера сборки

Выйдите из Xcode, затем перейдите в каталог, содержащий ваш файл проекта.xcodeproj в приложении Terminal, прежде чем выполнять любую из следующих команд. Файл проекта.xcodeproj содержит project.pbxproj, который используется agvtool. (Это часть, которую вы можете запустить в сценарии вместо командной строки.)

Обновление номера версии

Чтобы обновить номер версии до определенной версии, запустите

xcrun agvtool new-marketing-version <your_specific_version>

Пример: обновить номер версии до 2.0

xcrun agvtool new-marketing-version 2.0

Обновление номера сборки

Чтобы автоматически увеличить номер сборки, запустите

xcrun agvtool next-version -all

Чтобы установить номер сборки вашего приложения для конкретной версии, запустите

xcrun agvtool new-version -all <your_specific_version>

Пример: установить номер сборки на 2.6.9

xcrun agvtool new-version -all 2.6.9

Бонус:

Чтобы просмотреть номер текущей версии, запустите

xcrun agvtool what-marketing-version

Чтобы просмотреть текущий номер сборки, запустите

xcrun agvtool what-version
Источник

Вся эта запись была чрезвычайно полезной. Я использовал этот трюк, но настроил свой сценарий как ловушку после коммита в GIT, поэтому CFBundleVersion увеличивается после каждого успешного коммита. Скрипт хука идет в.git/hooks. Журнал остается в каталоге проекта.

Это соответствует моему основному критерию. Я хочу иметь возможность извлечь версию из GIT и перестроить ту сборку, которая была у меня ранее. Любые приращения, сделанные во время процесса сборки, этого не делают.

Вот мой сценарий:

#!/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
Источник

FWIW - это то, что я сейчас использую, чтобы увеличить номер сборки только для релизных сборок (включая архивирование). Хорошо работает под Xcode 5.1.

Просто скопируйте / вставьте фрагмент в фазу сборки сценария запуска непосредственно в 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;
Источник

Спасибо за сценарий. Работает отлично.

Мой Info.plist находится в подкаталоге с именем, содержащим пробелы, поэтому мне пришлось изменить Run Script с кавычками вокруг пути plist:

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

и сценарий оболочки таким же образом с кавычками вокруг всех путей:

#!/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
Источник

Сценарий, который я сейчас использую, очень похож на сценарий Аликс, описанный выше. Моя адаптация, ниже, добавляет проверку, чтобы делать автоинкремент только при сборке релиза / архива.

Без этого изменения будут конфликты контроля версий, так как каждый разработчик будет увеличивать номер сборки со своей скоростью. И тот факт, что история мерзавцев будет излишне загрязнена из-за постоянно меняющегося номера сборки.

# xcode-build-bump.sh
# @desc Auto-increment Xcode target build number every time the project is archived
# @src stackru.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}"

Он также доступен (в несколько более простом формате для копирования и вставки) в виде GitHub.

Источник

Я бы порекомендовал использовать автонаблюдение.

Xcode допускает файл заголовка (который может быть автоматически сгенерирован во время сборки, а не в самом vcs), чтобы обеспечить значения, которые будут раскрыты в info.plist во время сборки. Вы можете найти пошаговое руководство по настройке этого на веб-сайте автообзора.

Autorevision имеет тип вывода, ориентированный на заголовочные файлы этих типов, чтобы помочь именно в этих ситуациях.

Источник

Вы можете использовать универсальные версии Apple. В основном все, что вам нужно сделать, это позвонить agvtool next-version -all из каталога, в котором находится ваш файл.xcproj. Для более подробной информации проверьте URL выше.

Источник

Одна из проблем с некоторыми из этих решений заключается в том, что Launch Services распознает только четыре пять основных цифр в версии пакета. У меня есть проект с номером сборки, который исчисляется тысячами, поэтому я хотел использовать некоторые из менее значимых цифр.

Этот сценарий Perl увеличивает все Info.plists в проекте, а не только один для текущей цели, поэтому все номера сборки остаются в шаге. Он также использует одну цифру патча и две младшие цифры, поэтому сборка 1234 имеет версию 1.23.4. Я использую его как поведение перед сборкой, поэтому оно применимо ко всем проектам, которые я создаю.

Сценарий довольно грубый, но он работает для меня.

#!/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');
}
Источник

Основываясь на решении Уилла Гизелера, у меня было только одно изменение, которое я хотел сделать. Его решение помещает количество коммитов git в номер сборки. Полезно, но все еще немного сложно найти фактический коммит, который создал эту сборку. Меня не очень заботило, монотонно ли увеличивается номер сборки, и поэтому я отбросил это требование, чтобы легче было получить доступ к коммиту, который сгенерировал данный двоичный файл.

Для этого я изменил его первый сценарий следующим образом:

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

Это преобразует короткую версию текущего git SHA в десятичную. Шестнадцатеричные символы не очень хорошо соответствуют требованиям к номеру сборки Apple, поэтому я должен был это сделать. Чтобы преобразовать его обратно, вы просто запустите что-то вроде этого:

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

в баш, где <build number> это номер сборки, который вы получили из двоичного файла. Тогда просто беги git checkout $SHAи там вы идете.

Поскольку это адаптация решения Вила Гизелера, как упоминалось выше, вам также понадобится следующий сценарий после сборки:

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

который держит вашу историю Git в чистоте.

Источник

Вот обновленная версия. Это работает с Xcode 9.3.1, iOS 11.

Нажмите "Построить этапы" в целевом приложении, нажмите значок +, чтобы добавить новый сценарий выполнения, и в поле вставьте этот код.

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

Зайдите в файл Info.plist и установите для "Bundle version" значение 1, а для "Bundle version string, short" значение 1, вы должны быть установлены.

Создайте проект с использованием Info.plist, и вы увидите изменение версии Bundle (номер сборки).

  • Обратите внимание, что начиная с Xcode 9.3.1 вы не сможете увидеть эти изменения на вкладке "Общие", но увидите изменения при архивировании сборки и в Info.plist.
Источник

Я использую последнюю версию SVN для номера сборки. Если вы измените Info.plist в каталоге сборки, вы не будете влиять на исходный 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}'`
Источник

Я попытался изменить процедуру, и она не сработала, потому что:

  1. Xcode 4.2.1 изменяет подкаталог xcuserdata в.xcodeproj

  2. git отмечает предыдущее изменение в Project-Info.plist

Следующая модификация приводит к тому, что они игнорируются и помечают только подлинные изменения:

if [ -n "$(find $dir \! -path "*xcuserdata*" \! -path "*.git" -newer $plist)" ]; then
Источник

Я чувствую, что нашел свое племя. Племя, надеюсь, тебя позабавила версия X.

Десять лет назад, работая над рабочим пространством, в котором было более 25 проектов XCode, я воспользовался возможностью автоматизировать версию и создавать обновления строк до такой степени, которая может показаться абсурдной, если вы поддерживаете только один или два проекта со случайными обновлениями.

VersionX:

  • знает о типе сборки (Release / Debug)
  • собирает информацию во время сборки из репозитория (включая поддержку git, но может быть настроен для hg, svn или любого другого используемого вами)
  • предоставил легко настраиваемые строки причудливой маркетинговой версии (которые имели гораздо больше вариаций, прежде чем App Store наложил соглашение), чтобы вы могли автоматически увеличивать строки, которые включали символы для "беты", например, с использованием соглашения git-тегов.
  • включает в себя класс, заполненный переменными экземпляра, содержащими информацию о версии и фиксации. Это полезно для заполнения панели about about и создания строк регистрации, отчетов о сбоях или сообщений об ошибках пользователей по электронной почте с предварительно заполненной информацией.

Это было весело сделать. Я узнал много о системе сборки Xcode.

Вот пример типа причудливой версии и строк сборки, которые VersionX может генерировать автоматически.

Версия X 1.0.1 β7 (c5959a3 "Чистый")

Маркетинговая версия: VersionX 1.0.1 β7 "1.0.1 является производным от тега для фиксации, в то время как" Beta 7 "автоматически генерируется счетчиком коммитов или счетчиком сборок (например).

Версия сборки: (c5959a3 "Очистить") Отображает хеш короткой фиксации и информирует вас о том, что в каталоге сборки не было ни одного незафиксированного изменения.

VersionX (источник на GitHub) - система в стиле барокко для автоматического увеличения версии и построения строк в проектах Xcode.

Документация VersionX.

Источник

Возможно, вы захотите сделать это только тогда, когда вы архивируете (и загружаете в TF, например). В противном случае номер вашей версии может очень быстро возрасти.

В схему (Product / Edit Scheme / Archive / Pre-Actions) вы можете добавить скрипт, который будет выполняться только при архивации.

Кроме того, вы можете сбросить номер сборки при каждом увеличении версии приложения.

И последнее, если вы используете архив вместо этого, вы можете безопасно отключить:

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

Поскольку номер сборки будет увеличиваться только при архивировании...

РЕДАКТИРОВАТЬ: Исправьте то, что я сказал, предварительные действия в архиве происходят после сборки (но до архивирования), так что номер сборки будет увеличиваться для следующего архива... Но вы можете создать новую схему и добавить это действие в сборку (предварительно действия) раздел этой новой схемы. и использовать эту схему, когда вы хотите создать новую сборку

Источник

Я обновляю build number по следующему методу.

$INFO_FILE путь к файлу plist А также $build_number это новый номер сборки для этого здания.

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

Вообще мой $build_number состоит из major а также minor частей. minor это из информации о проекте. Итак, я опишу, как генерировать 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}"

У меня есть 2 стратегии, чтобы решить $build_number,

Первая стратегия

Эта стратегия использует git tag рассчитывать, чтобы решить major из build number, Если есть 53 теги проекта, он вернется 53 следуя сценарию оболочки.

Как правило, это увеличивается. И это заставит разработчика поставить тег git перед публикацией.

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

Вторая стратегия

Пусть система Jenkins CI решит major часть. Имеет переменную окружения BUILD_NUMBER, Он увеличивается автоматически при построении системы CI. Эта информация полезна для отслеживания истории проекта в системе CI.

major_number=${BUILD_NUMBER}
Источник

Возможно, вы захотите проверить новый инструмент, который я разрабатывал, под названием Xcodebump. Он может обрабатывать обновление как CFBundleShortVersionString, так и CFBundleVersion. В качестве последнего шага он также пометит git и пометит коммит, чтобы он соответствовал этим значениям CFBundle.

Проект Xcodebump находится здесь:

https://github.com/markeissler/Xcodebump

Источник

Вот мое решение. Если вы похожи на меня: терминал дружелюбен, как рубин, как семантическая версия, попробуйте это.

Сделайте файл с именем Rakefile который содержит это:

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
}

Подготовить: gem install xcodeproj versionomy

Бежать: rake increment:major или же rake increment:minor или же rake increment:tiny когда угодно.

Источник

Давайте сделаем это по-своему. Номер сборки будет увеличиваться после каждой успешной сборки.

Я проведу вас через 5 изображений, просто просмотрите их.

  1. Выберите "Изменить схему..." из раскрывающегося списка, когда вы выберете имя своего проекта, расположенное справа от кнопки Stop_build_button. Проверить первый шаг

  2. В меню leftSide разверните опцию "Build" и выберите "Post-actions" Проверить второй шаг.

  3. Здесь вы можете добавить желаемые коды (сценарии), которые хотите выполнить после успешной сборки вашей программы. Это место, где мы должны добавить немного кода, чтобы наша автоматизация работала идеально. >> 1. нажмите кнопку "добавить (+)" в левом углу, чтобы добавить новый файл сценария. >> 2. Теперь в раскрывающемся списке выберите "Создать действие сценария выполнения". Отметьте третий шаг.

  4. Он имеет 3 поля >> 1. оболочка уже назначена для вас >> 2. теперь для "Предоставить вам настройки сборки из" выберите имя вашего проекта. >> 3. Есть большое поле для добавления вашего скрипта, просто скопируйте и вставьте туда этот код: Отметьте четвертый шаг

    PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}" PLB=/usr/libexec/PlistBuddy LAST_NUMBER=$($PLB -c "Print CFBundleVersion" "$PLIST") NEW_VERSION=$(($LAST_NUMBER + 1)) $PLB -c "Установить:CFBundleVersion $NEW_VERSION" "$PLIST"

  5. После завершения 4-го шага просто выберите "Закрыть", чтобы закрыть окно, и мы должны сделать последний шаг, перейдите к вашему файлу "plist.info" в меню файла проекта и убедитесь, что ключ "Версия пакета" в разделе "Ключ" больше всего Проверка числового значения Пятый шаг

Источник

Я считаю наиболее удобным использовать Automating Version и номера сборки с помощью agvtool.

Попробуй это:

  1. Настройте его, как описано в документации Apple, ссылка на которую приведена выше.
  2. Добавить сценарий в качестве предварительного действия в Project -> Edit Scheme... -> Archive (или другой, если хотите)
  3. Set: предоставить настройки сборки из <your_app_target>

Скрипт (первая строка необязательна):

exec > ${PROJECT_DIR}/prebuild.log 2>&1
cd ${PROJECT_DIR}
xcrun agvtool next-version -all
cd -
Источник
Другие вопросы по тегам