Używałem skryptu powłoki jako części mojego procesu kompilacji Xcode w celu zwiększenia numeru kompilacji w pliku plist , jednak często powoduje to awarię Xcode 4.2.1 (z błędem dotyczącym celu nie należącego do projektu; zgaduję zmiana pliku plist w pewien sposób wprowadza w błąd Xcode).

Skrypt powłoki zrobił to tak, że numer kompilacji jest zwiększany tylko agvtoolwtedy, gdy plik jest nowszy niż plik plist (więc samo zbudowanie nie zwiększyło wartości):

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

Czy istnieje sposób na zwiększenie numeru kompilacji (w pliku plist lub gdziekolwiek indziej), który nie zepsuje Xcode?

EDYCJA KOŃCOWA : Teraz robię tego rodzaju rzeczy za pomocą skryptu Pythona, który właśnie opublikowałem na githubie . Nie jest to dobrze udokumentowane, ale nie powinno być trudne do rozwiązania. Jako bonus, to repozytorium zawiera również przydatny skrypt do automatycznego łączenia biblioteki innej firmy w pakiet aplikacji.

Jeśli dobrze rozumiem Twoje pytanie, chcesz zmodyfikować Project-Info.plistplik, który jest częścią standardowego szablonu projektu Xcode?

Powodem, dla którego o to pytam, jest to, że Project-Info.plistnormalnie znajduje się pod kontrolą wersji, a modyfikacja oznacza, że ​​zostanie oznaczona jako, no cóż, zmodyfikowana.

Jeśli to nie przeszkadza, następujący fragment kodu zaktualizuje numer kompilacji i oznaczy plik jako zmodyfikowany w procesie, gdzie get_build_numberjest jakiś skrypt (tj. Symbol zastępczy w tym przykładzie), aby uzyskać (prawdopodobnie zwiększony) numer kompilacji, który chcesz użyć:

#!/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 pozwala ustawić dowolny klucz w pliku plist, nie tylko numer wersji. Możesz utworzyć wszystkie potrzebne pliki plist i w razie potrzeby dołączyć je do zasobów. Następnie można je wczytać z pakietu.

Jeśli chodzi o potrzebę pokazania wersji w okienku informacji i innych miejscach, możesz również zajrzeć do ustawień CFBundleGetInfoStringi CFBundleShortVersionString.

Grzebałem w wielu odpowiedziach na to pytanie i żadna z nich nie zadowoliła mnie. Jednak w końcu wymyśliłem mieszankę, którą naprawdę lubię!

Istnieją dwa kroki, jeden na początku i jeden na końcu faz budowy.

Na początku:

# 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

Na końcu:

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

Patrząc na Info.plist w Xcode, zobaczysz, że numer wersji to „ROZWÓJ”, ale zbudowana aplikacja będzie miała stale rosnący numer wersji. (O ile zawsze budujesz konstrukcje z tej samej gałęzi).

Ustawienie numeru wersji z powrotem na stały ciąg na końcu zapobiega zmianie pliku Info.plist przez zbudowanie aplikacji.

Dlaczego podoba mi się ta metoda:

• Łatwo
• Nie zanieczyszcza historii wersji Git
• CFBundleVersion jest całkowicie automatyczny
• Ładny numer wersji można modyfikować w dowolnym momencie

Użyłem tego glisty. Działa zgodnie z oczekiwaniami. https://gist.github.com/sekati/3172554 (wszystkie zasługi należą do oryginalnego autora)

Skrypty, które z czasem modyfikowałem.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Ponieważ te treści pomagają społeczności deweloperów, stworzyłem z tego projekt GitHub. Rozwińmy więc to dobrze. Oto projekt GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Zaktualizowałem kod dla obu skryptów, nieco ulepszając. zamiast używać poniższego, pobierz najnowsze z GitHub

Wersja:

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

Do budowy:

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

Cały ten wpis był niezwykle pomocny. Użyłem tej sztuczki, ale skonfigurowałem mój skrypt jako punkt zaczepienia po zatwierdzeniu w GIT, więc wartość CFBundleVersion jest zwiększana po każdym udanym zatwierdzeniu. Skrypt przechwytujący trafia do .git / hooks. Dziennik pozostaje w katalogu projektu.

To spełnia moje najbardziej podstawowe kryterium. Chcę móc pobrać wersję z GIT i odbudować dokładnie taką wersję, jaką miałem wcześniej. Żadna inkrementacja wykonana podczas procesu budowania tego nie robi.

Oto mój skrypt:

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

Nie wiem, która droga jest najlepsza, ale opublikuję odpowiedź Apple na wypadek, gdyby ktoś jej szukał ...

Zgodnie z tym postem z pytaniami i odpowiedziami firmy Apple :

Automatyzacja numerów wersji i kompilacji za pomocą agvtool

Klucze wersji i numeru kompilacji określają odpowiednio marketingową i wewnętrzną wersję aplikacji. agvtool to narzędzie wiersza poleceń, które umożliwia automatyczne zwiększanie tych liczb do kolejnej największej liczby lub do określonej liczby.

Numer kompilacji wskazuje niewydaną lub wydaną wersję aplikacji. Jest przechowywany w Info.plist aplikacji jako CFBundleVersion(Wersja pakietu).

W projekcie Xcode musisz wykonać następujące kroki:

1. Włącz agvtool

Przejdź do okienka Ustawienia kompilacji celu, a następnie zaktualizuj go dla wszystkich konfiguracji kompilacji w następujący sposób:

• Ustaw bieżącą wersję projektu na wybraną wartość.

Plik danych projektu Xcode, project.pbxproj, zawiera CURRENT_PROJECT_VERSIONustawienie kompilacji (bieżąca wersja projektu), które określa bieżącą wersję projektu. agvtool wyszukuje plik project.pbxproj CURRENT_PROJECT_VERSION. Kontynuuje działanie, jeśli CURRENT_PROJECT_VERSIONistnieje, i przestaje działać, w przeciwnym razie. Jego wartość służy do aktualizacji numeru kompilacji.

• Ustaw system wersjonowania na Apple Generic.

Domyślnie Xcode nie używa żadnego systemu wersjonowania. Ustawienie systemu obsługi wersji na Apple Generic gwarantuje, że Xcode będzie zawierał wszystkie informacje o wersji wygenerowane przez agvtool w projekcie.

2. Skonfiguruj wersję i numery kompilacji

agvtool przeszukuje Info.plist twojej aplikacji pod kątem twojej wersji i numeru kompilacji. Aktualizuje je, jeśli istnieją, i nic nie robi, w przeciwnym razie. Upewnij się, że klucze CFBundleVersion(Wersja pakietu) i CFBundleShortVersionString( Wersja pakietu, krótkie) istnieją w Info.plist, jak widać na poniższym obrazku:

Zamknij Xcode, a następnie przejdź do katalogu zawierającego plik projektu .xcodeproj w aplikacji Terminal przed uruchomieniem któregokolwiek z poniższych poleceń. Plik projektu .xcodeproj zawiera project.pbxproj, który jest używany przez agvtool. (Jest to część, którą można uruchomić w skrypcie zamiast w wierszu poleceń).

Aktualizacja numeru wersji

Aby zaktualizować numer wersji do określonej wersji, uruchom

xcrun agvtool new-marketing-version <your_specific_version>

Np .: Zaktualizuj numer wersji do 2.0

xcrun agvtool new-marketing-version 2.0

Aktualizacja numeru kompilacji

Aby automatycznie zwiększyć numer kompilacji, uruchom

xcrun agvtool next-version -all

Aby ustawić numer kompilacji aplikacji na określoną wersję, uruchom

xcrun agvtool new-version -all <your_specific_version>

Przykład: ustaw numer kompilacji na 2.6.9

xcrun agvtool new-version -all 2.6.9

Premia:

Aby wyświetlić aktualny numer wersji, uruchom

xcrun agvtool what-marketing-version

Aby wyświetlić aktualny numer kompilacji, uruchom

xcrun agvtool what-version

FWIW - to jest to, czego obecnie używam, aby zwiększyć numer kompilacji tylko dla wersji wydania (co obejmuje archiwizację). Działa dobrze pod Xcode 5.1.

Po prostu skopiuj / wklej fragment kodu do fazy budowania skryptu Uruchom bezpośrednio w 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;

Dzięki za scenariusz. Działa świetnie.

Moja Info.plist znajduje się w podkatalogu o nazwie zawierającej spacje, więc musiałem zmodyfikować skrypt uruchamiania za pomocą cudzysłowów wokół ścieżki plist:

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

i skrypt powłoki w ten sam sposób z cudzysłowami wokół wszystkich ścieżek:

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

Skrypt, którego obecnie używam, jest bardzo oparty na skrypcie Alix powyższym . Moja adaptacja, poniżej, dodaje sprawdzenie, aby wykonać automatyczną inkrementację tylko w kompilacji wydania / archiwum.

Bez tej zmiany wystąpią konflikty kontroli wersji, ponieważ każdy programista będzie zwiększał numer kompilacji we własnym tempie. I fakt, że historia gita byłaby niepotrzebnie zanieczyszczona przez cały czas zmieniający się numer kompilacji.

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

Jest również dostępny (w nieco łatwiejszym do skopiowania i wklejania formacie) jako treść GitHub .

Poleciłbym korzystanie z autorewizji .

Xcode pozwala na plik nagłówkowy (który może być generowany automatycznie w czasie kompilacji, a nie w samym pliku vcs) na dostarczanie wartości, które zostaną rozwinięte w info.plist podczas kompilacji. Przewodnik, jak to zrobić, znajdziesz na stronie autorewizji .

Autorevision ma typ wyjścia dostosowany do plików nagłówkowych tego typu, aby pomóc w dokładnie takich sytuacjach.

Jednym z problemów z niektórymi z tych rozwiązań jest to, że Launch Services rozpoznaje tylko cztery pięć głównych cyfr w wersji pakietu . Mam projekt z numerem kompilacji w tysiącach, więc chciałem użyć mniej znaczących cyfr.

Ten skrypt Perla inkrementuje wszystkie listy Info.plist w projekcie, a nie tylko ten dla bieżącego celu, więc wszystkie numery kompilacji pozostają nierozłączne. Używa również jednej cyfry poprawki i dwóch mniejszych cyfr, więc kompilacja 1234 ma wersję 1.23.4. Używam go jako zachowania przed kompilacją, więc dotyczy wszystkich projektów, które buduję.

Scenariusz jest dość brutalny, ale dla mnie działa.

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

Możesz użyć generycznej wersji Apple . Zasadniczo wszystko, co musisz zrobić, to zadzwonić agvtool next-version -allz katalogu, w którym znajduje się plik .xcproj. Aby uzyskać więcej informacji, sprawdź powyższy adres URL.

Opierając się na rozwiązaniu Wil Gieselera , miałem tylko jedną zmianę, którą chciałem wprowadzić. Jego rozwiązanie umieszcza liczbę zatwierdzeń git w numerze kompilacji. Przydatne, ale wciąż trochę uciążliwe, aby znaleźć rzeczywiste zmiany, które stworzyły tę kompilację. Nie obchodziło mnie zbytnio, czy numer kompilacji rośnie monotonicznie, więc zrezygnowałem z tego wymagania, aby łatwiej uzyskać dostęp do zatwierdzenia, które wygenerowało dany plik binarny.

W tym celu zmodyfikowałem jego pierwszy skrypt do następującego:

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

To konwertuje krótką wersję bieżącego git SHA na dziesiętną. Znaki szesnastkowe nie działają dobrze z wymaganiami dotyczącymi numeru kompilacji Apple, dlatego musiałem to zrobić. Aby go przekonwertować, po prostu uruchomisz coś takiego:

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

w bash, gdzie <build number>jest numer kompilacji uzyskany z pliku binarnego. Następnie po prostu biegnij git checkout $SHAi gotowe.

Ponieważ jest to adaptacja rozwiązania Wil Gieselera , jak wspomniano powyżej, będziesz również potrzebować następującego skryptu po kompilacji:

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

dzięki czemu Twoja historia git jest czysta.

Wypróbowałem zmodyfikowaną procedurę i nie zadziałała, ponieważ: -

1. Xcode 4.2.1 zmienia podkatalog xcuserdata w .xcodeproj

2. git zauważa poprzednią zmianę w Project-Info.plist

Następująca modyfikacja powoduje, że są one ignorowane i sygnalizuje tylko prawdziwe zmiany: -

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

Możesz to zrobić tylko wtedy, gdy archiwizujesz (i na przykład przesyłasz do TF). W przeciwnym razie numer Twojej wersji może wzrosnąć naprawdę szybko.

W schemacie (Produkt / Edycja schematu / Archiwum / Działania wstępne) możesz dodać skrypt, który będzie wykonywany tylko podczas archiwizacji.

Możesz też chcieć zresetować numer kompilacji za każdym razem, gdy zwiększasz wersję aplikacji.

Ostatnia rzecz, jeśli zamiast tego używasz archiwum, możesz bezpiecznie wyłączyć:

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

Ponieważ numer kompilacji zostanie zwiększony tylko podczas archiwizacji ...

EDYCJA: Popraw to, co powiedziałem, działania wstępne w archiwum mają miejsce po kompilacji (ale przed archiwizacją), więc numer kompilacji będzie zwiększany dla następnego archiwum ... Ale możesz utworzyć nowy schemat i dodać tę akcję w kompilacji (przed czynności) tego nowego schematu. i użyj tego schematu, gdy chcesz utworzyć nową kompilację

Używam ostatniej wersji SVN jako numeru kompilacji. Jeśli zmienisz Info.plist w katalogu kompilacji, nie wpłyniesz na źródło 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}'`

Czuję, że znalazłem swoje plemię. Plemię, mam nadzieję, że VersionX cię bawi.

Dziesięć lat temu, pracując nad obszarem roboczym, w którym znajdowało się ponad 25 projektów Xcode, skorzystałem z okazji, aby zautomatyzować wersję i zbudować aktualizacje ciągów w stopniu, który może wydawać się absurdalny, jeśli utrzymujesz tylko jeden lub dwa projekty z okazjonalnymi aktualizacjami.

WersjaX:

• zna typ kompilacji (wydanie / debugowanie)
• zbiera informacje w czasie kompilacji z repozytorium (w tym obsługa git, ale można je dostosować do hg, svn lub czegokolwiek innego)
• zapewniono łatwe do dostosowania, fantazyjne ciągi wersji marketingowych (które miały znacznie więcej odmian, zanim App Store narzucił konwencję), dzięki czemu można było automatycznie zwiększać ciągi, które zawierały symbole „beta”, na przykład przy użyciu konwencji tagów git.
• zawiera klasę wypełnioną zmiennymi instancji zawierającymi informacje o wersji i zatwierdzeniu. Jest to przydatne do wypełniania panelu informacji i tworzenia ciągów rejestrowania, raportów o awariach lub raportów o błędach poczty e-mail użytkowników z wstępnie wypełnionymi informacjami.

Fajnie było zrobić. Dowiedziałem się dużo o systemie kompilacji Xcode.

Oto przykład typu fantazyjnych ciągów wersji i kompilacji, które VersionX może wygenerować automatycznie.

WersjaX 1.0.1 β7 (c5959a3 „Wyczyść”)

Wersja marketingowa: WersjaX 1.0.1 β7 „1.0.1 pochodzi ze znacznika zatwierdzenia, podczas gdy„ Beta 7 ”jest automatycznie generowana przez liczbę zatwierdzeń lub liczbę kompilacji (na przykład).

Wersja kompilacji: (c5959a3 „Wyczyść”) Wyświetla skrót skrótu zatwierdzenia i informuje, że w katalogu kompilacji nie było żadnych niezatwierdzonych zmian.

VersionX (źródło w GitHub) - barokowy system do automatycznego zwiększania wersji i tworzenia ciągów znaków w projektach Xcode.

Dokumentacja VersionX.

Możesz sprawdzić nowe narzędzie, które opracowałem, o nazwie Xcodebump. Może obsługiwać aktualizację zarówno CFBundleShortVersionString, jak i CFBundleVersion. Ostatnim krokiem będzie również sprawdzenie git i oznaczenie commit w celu dopasowania do tych wartości CFBundle.

Projekt Xcodebump znajduje się tutaj:

https://github.com/markeissler/Xcodebump

Aktualizuję build numbernastępującą metodą.

$INFO_FILEto ścieżka do pliku plist. A $build_numberto nowy numer kompilacji dla tego budynku.

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

Ogólnie mój $build_numberskłada się z części majori minor. minorJest pochodzą z informacji o projekcie. Więc opisuję, jak wygenerować majorczęść.

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

Mam dwie strategie, aby zdecydować $build_number .

Pierwsza strategia

Ta strategia używa git tagliczby do decydowania majoro build number. Jeśli istnieją 53tagi projektu, zwróci on, 53wykonując następujący skrypt powłoki.

Ogólnie rzecz biorąc, rośnie. I zmusi programistę do umieszczenia tagu git przed publikacją.

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

Druga strategia

Niech system CI Jenkinsa zdecyduje o majorczęści. Ma zmienną środowiskową BUILD_NUMBER. Zwiększa się automatycznie podczas tworzenia systemu CI. Te informacje są przydatne do śledzenia historii projektu w systemie CI.

major_number=${BUILD_NUMBER}

Oto zaktualizowana wersja. Działa od Xcode 9.3.1, iOS 11.

Kliknij „Fazy budowania” w miejscu docelowym aplikacji, kliknij ikonę +, aby dodać nowy skrypt uruchamiania, a następnie w polu wklej ten kod.

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

Przejdź do pliku Info.plist i ustaw „Wersja pakietu” na 1, a „Łańcuch wersji pakietu, krótkie” na 1, powinno być ustawione.

Zbuduj projekt z podglądem Info.plist i powinieneś zobaczyć zmianę wersji pakietu (numer kompilacji).

• Zwróć uwagę, że od wersji Xcode 9.3.1 nie będziesz w stanie zobaczyć tych zmian na karcie Ogólne, ale zobaczysz je po zarchiwizowaniu kompilacji oraz w Info.plist

Oto moje rozwiązanie. Jeśli jesteś podobny do mnie: przyjazny terminalowi, jak ruby, jak wersjonowanie semantyczne, spróbuj tego.

Utwórz plik o nazwie, Rakefilektóry zawiera to:

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
}

Przygotować: gem install xcodeproj versionomy

Run: rake increment:majorczy rake increment:minorlub rake increment:tinykiedy chcesz.

Uważam, że najwygodniejsze jest użycie automatyzacji wersji i numerów kompilacji za pomocą agvtool .

Spróbuj tego:

1. Skonfiguruj go zgodnie z opisem w dokumentacji Apple, do której link znajduje się powyżej.
2. Dodaj skrypt jako działanie wstępne do projektu -> Edytuj schemat ... -> Archiwum (lub inne, jeśli wolisz)
3. Zestaw: podaj ustawienia kompilacji z <your_app_target>

Skrypt (pierwsza linia jest opcjonalna):

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

Zróbmy to na swój sposób Apple. Zwiększy numer kompilacji po każdej udanej kompilacji

Poprowadzę Cię przez 5 obrazów, po prostu je przejrzyj.

1. Wybierz „Edytuj schemat ...” z menu rozwijanego, po wybraniu nazwy projektu znajdującej się po prawej stronie przycisku Stop_build_button. Sprawdź pierwszy krok

2. Z menu po lewej stronie rozwiń opcję „Buduj” i wybierz „Działania po wykonaniu” Sprawdź drugi krok

3. Tutaj możesz dodać żądane kody (skrypty), które chcesz wykonać po udanej kompilacji programu. Jest to miejsce, w którym musimy dodać trochę kodu, aby nasza automatyzacja działała idealnie. >> 1. wybierz przycisk 'dodaj (+)' z lewego rogu, aby dodać nowy plik skryptu >> 2. Teraz z listy rozwijanej wybierz 'Nowa akcja skryptu uruchamiania' Sprawdź trzeci krok

4. Zawiera 3 pola >> 1. powłoka jest już przypisana do ciebie >> 2. teraz dla „Podaj ustawienia budowania z” Wybierz nazwę projektu. >> 3. Tam jest duże pole do dodania skryptu, po prostu skopiuj i wklej tam ten kod: Sprawdź czwarty krok

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

5. Po wykonaniu czwartego kroku po prostu wybierz „Zamknij”, aby zamknąć okno i musimy zrobić ostatni krok, przejdź do pliku „plist.info” w menu Plik projektu i upewnij się, że klucz „Wersja pakietu” w sekcji „Klucz” zawiera najwięcej Piąty krok sprawdzania wartości liczbowych