Lepszy sposób na zwiększenie numeru kompilacji?

133

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.

trojanfoe
źródło
1
Jeśli ktoś jest zainteresowany: zmodyfikowałem trochę skrypt, aby używać liczb szesnastkowych zamiast liczb dziesiętnych - gist.github.com/sascha/5398750
Sascha
1
Możesz dodać ten skrypt bezpośrednio jako akcję przed kompilacją, bez konieczności wywoływania skryptu zewnętrznego. Nie uruchamiaj tego skryptu z fazą kompilacji; Xcode skopiuje zaktualizowaną listę plist tylko co drugą kompilację.
Ed McManus
3
Po wyjęciu z pudełka otrzymałem błąd „Odmowa pozwolenia”, więc pomyślałem, że wskazałbym to pytanie i odpowiedzi każdemu, kto doświadcza tego samego: stackoverflow.com/q/9850936/519030
Jason
Ten skrypt kończy się niepowodzeniem z kodem zakończenia 1. Czy ktoś może mi w tym pomóc?
Robert J. Clegg
@Tander Wygląda na to, że nie dostarczasz pliku plist jako argumentu do skryptu.
trojanfoe

Odpowiedzi:

29

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.

Monolo
źródło
Nie potrzebuję zatwierdzenia git (lub tagu) w pliku plist , więc prosty system inkrementacji jest w porządku (jak zapewnia agvtool), jednak akt modyfikowania pliku plist podczas kompilacji często psuje Xcode (od usunięcia skryptu nie ma ' awaria raz, gdy ulegała awarii co około 3 kompilacje). Czy można umieścić informacje o wersji w innym pliku plist i dołączyć je do pakietu i uzyskać do nich dostęp z poziomu aplikacji?
trojanfoe
Świetny skrypt - wolałbym połączyć to z sugestią Hugues BR , aby używać go tylko podczas archiwizowania kompilacji. Utrzymuje niskie liczby i ignoruje liczbę kompilacji deweloperskich wykonywanych między wydaniami.
Jay
5
Co to jest get_build_number? Czy to tylko symbol zastępczy?
chrisp
Tak, get_build_numberto tylko symbol zastępczy - zaktualizowano odpowiedź w celu wyjaśnienia.
Monolo
72

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
Wil Gieseler
źródło
Unikanie numerów wersji w pliku plist z kontrolą wersji jest najlepszym sposobem, aby to zrobić, zwłaszcza jeśli masz brach na wydanie i czasami trzeba scalać lub wybierać. Dzięki!
Matthew Phillips,
14
Możesz użyć git rev-list --count HEADzamiast git rev-list HEAD | wc -l | tr -d ' '.
kennytm
Hmm. Zauważyłem, że jeśli używasz fastlanedo przesyłania automatycznych kompilacji w ten sposób, otrzymujesz: BŁĄD ITMS-90058: "Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleVersion [DEVELOPMENT] w pliku Info.plist musi być rozdzieloną kropkami listą at większość trzech nieujemnych liczb całkowitych. "
fatuhoku
1
Nie jestem pewien, gdzie powinien się udać, pierwszy skrypt umieściłem jako pierwszą fazę kompilacji, a ostatni skrypt jako ostatnią fazę kompilacji i działa dla mnie.
Wil Gieseler
1
Zdecydowanie możesz zatwierdzić Info.plist za pomocą tego rozwiązania - o to chodzi. Info.plist jest zawsze ustawiane i rejestrowane z numerem wersji ustawionym na „DEVELOPMENT”, jest tymczasowo zmieniany podczas procesu budowania, a następnie ponownie ustawiany na „DEVELOPMENT”, dzięki czemu Info.plist jest stabilny.
Wil Gieseler
38

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}"
Alix
źródło
To zawsze spowoduje zwiększenie numeru kompilacji, ponieważ chciałem, aby zwiększał się tylko w przypadku zmiany pliku źródłowego. To tylko skrypt, którego obecnie używam, z mniejszą liczbą sprawdzeń bezpieczeństwa i mniej dostrzegający, co się zmieniło.
trojanfoe
XCode 5: Edytor (pasek menu) → Dodaj fazę kompilacji → Dodaj fazę tworzenia kopii plików:
Jonny
@trojanfoe: Możesz uruchomić ten skrypt jako punkt zaczepienia po zatwierdzeniu. W tym scenariuszu liczba kompilacji zwiększy się tylko wtedy, gdy zdecydujesz się zatwierdzić kod do repozytorium. Odpowiedź poniżej od LostInTheTrees to coś więcej, co możesz chcieć zrobić.
Alix
Skrypty powłoki, do których prowadzi @Alix, są teraz zupełnie inne niż te opublikowane tutaj. Aby zwiększyć numer kompilacji tylko podczas tworzenia kompilacji archiwum, możesz użyć streszczenia, które zrobiłem, bardzo na podstawie powyższych skryptów Alix, tutaj: gist.github.com/mattpotts/abcffea6d08ad45739ef
Matthew
14

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
LostInTheTrees
źródło
Mam to samo wymaganie, dlatego numer kompilacji jest zwiększany tylko wtedy, gdy plik źródłowy został zmodyfikowany. Zauważyłem, że działa to bardzo dobrze i nie musiałem wprowadzać zmian w bump_build_number.shskrypcie od czasu jego powstania.
trojanfoe,
14

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.

Ustaw system wersjonowania na Apple Generic

  1. 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:

Skonfiguruj wersję i numery kompilacji

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
FormigaNinja
źródło
7
Problem z tym jest taki, że agvtool przerwie kompilację xcode, więc nie można go zintegrować jako skryptu w fazach kompilacji.
Daniel Schlaug
1
Czy nie mógłbyś po prostu umieścić bump via agvtool w działaniach wstępnych kompilacji schematu?
lottadot
11

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;
Sójka
źródło
Jak można zwiększyć wartość CFBundleVersion? W Xcode 5.1 jest to ciąg w formacie „1.0”?
chrisp
1
Wreszcie ktoś robi to dobrze :) Dlaczego miałbym przejmować się każdą kompilacją, którą uruchamiam na moim urządzeniu deweloperskim? Liczą się wydania (i wydania testerom), a nie kompilacje „hmm, przesuń te 2 piksele w lewo”.
uvesten
7

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
massimobio
źródło
Tak, to ma sens. Cieszę się, że jest to przydatne; Od tego czasu używam bez żadnych problemów pod Xcode 4. {2,3,4,5}.
trojanfoe,
Zaoszczędziłbym sobie kilka godzin, gdybym zobaczył tę odpowiedź! Należy również pamiętać, że numer kompilacji hte nie może mieć ułamka dziesiętnego, w przeciwnym razie BASH ulegnie awarii.
Brenden,
6

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 .

Mateusz
źródło
5

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.

dak180
źródło
1
Autorevisionnie wydaje się zmieniać numeru kompilacji, zgodnie z wymaganiami?
trojanfoe
Zakładając, że buduje się tylko na nowym zatwierdzeniu, VCS_NUMpowinno być tym, czego szukasz ( zobacz autorevision.hprzykład ).
dak180
Vienna-Info.plist i Vienna-All.xcconfig są dobrym przykładem tego, jak można to ustawić w dowolnym projekcie xcode.
dak180
4

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');
}
Brent Royal-Gordon
źródło
W poście, który cytujesz, czytamy, że „ LS oczekuje następującego formatu: nnnnn [.nn [.nn]] [X], gdzie n to cyfra 0-9, nawiasy kwadratowe oznaczają opcjonalne składniki, a X to dowolny ciąg nie zaczynając od cyfry. X jest ignorowane, jeśli występuje. '- więc to jest kompilacje 99999. Powinno wystarczyć dla większości projektów ..?
Jay
@Jay Najwyraźniej źle odczytałem to jako cztery cyfry. Ups. (Mimo to, jeśli twój styl programowania wymaga wielu poprawek i przebudowy, nie jest wykluczone, że możesz osiągnąć 100 000 kompilacji po latach tworzenia projektu).
Brent Royal-Gordon
@ BrentRoyal-Gordon True - poprawiłem mój skrypt kompilacji tak, aby zwiększał kompilacje tylko dla konfiguracji wydania .. mimo że prawdopodobnie nigdy nie osiągnąłem poziomu zbliżonego do 10k kompilacji, nawet z moim ponad 10-letnim starszym produktem, to miło jest mieć mnóstwo miejsca na głowę dzięki nowym projektom Cocoa ;-)
Jay
4

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.

Valentin Radu
źródło
3
Problem z tym rozwiązaniem polega na tym, że wywołanie agvtool z poziomu skryptu w projekcie spowoduje anulowanie kompilacji. To nie jest dobre rozwiązanie, chyba że możesz znaleźć obejście tego problemu.
Dan Loewenherz
3

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.

ravron
źródło
Więc jak to działa, biorąc pod uwagę, że będziesz zapisywać informacje git Info.plist, które są śledzone przez git?
trojanfoe
@trojanfoe Jak wspomniałem u góry odpowiedzi, ta odpowiedź jest adaptacją rozwiązania Wila Gieselera. W związku z tym wymaga tego samego skryptu po kompilacji, który został tam użyty. Dodałem to wyraźnie do odpowiedzi.
ravron
2

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
Milliways
źródło
2

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ę

Hugues BR
źródło
1
Tak, szybko rośnie (w tej chwili 5500+), ale to nie jest dla mnie problem; to tylko liczba. Ciekawe, ile razy Cmd-B / Cmd-R zostaje trafiony, zanim cokolwiek
zadziała
2

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}'`
Jacek
źródło
2

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.

Gary W. Longsine
źródło
1

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

markeissler
źródło
1

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}
AechoLiu
źródło
1

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
L. Davis
źródło
0

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.

zacier
źródło
0

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 -
goce
źródło
0

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

Debashish Das
źródło