Gitを使用してXcodeで複数の開発者が作業する新しいプロジェクトを開始しています。自動インクリメントのビルド番号を設定したいのですが、これを行う方法についていくつかの良い答えを見つけましたが、私の懸念は複数の開発者とGitにあります。
Xcodeには、プロジェクトファイルのように、非常に機密性が高く、マージが難しいファイルがいくつかあることを知っています。ビルド番号を自動インクリメントするために私が見た中で最高のテクニックは、同じ複数のGitマージの問題の影響を受けやすいでしょう。
自動インクリメントビルド手法を使用して、マージの問題を最小限に抑える方法について、ここにガイダンスはありますか？良い答えはないのかもしれませんが、他の人が何をしているのか知りたいです。
それで、最初に彼の答えとコメントをくれたharaldに感謝します。それは、私が本当に達成したいことをよりよく考えるのに役立ちました。
私の考え、やりたいことに気づいたこと、そしてそれをどのようにしたかを要約しましょう。
自動化された方法でビルド番号（CFBundleVersion）を入力する方法が必要でした。この値は、ソース制御されているメインプロジェクトの-Info.plistファイルに保存されます。私は、「ビルドフェーズ」スクリプトを介してこれを自動化するためのガイドに従うことを懸念していました。それは、おそらく複数の開発者のためにこのファイルを変更し、絶え間ないマージが必要になる状況を引き起こすからです。
これが必要な理由は、特定のビルドでどのコードが使用されているかを簡単に追跡できるようにするためです。タグ付けと適切なドキュメントを使用して手動でこれを行うことは確かに可能ですが、TestFlightに対して多くのビルドが行われると思うので、より自動化された柔軟な方法が必要でした。
私の当初の考えは、この値に単純な増分ビルド番号を使用することでしたが、それはマージの問題になります。GitリポジトリでコミットSHAを使用するというハラルドの提案は、私にとってより良い考え方を引き起こしました。
したがって、私のソリューションの最初の部分は、コミットSHAの最初の9文字を使用することです（SHAは長すぎます）。GitLab HQ（ちなみに素晴らしいオープンソースプロジェクト）を実行しているので、最初の9文字を使用し、実行中のコミットストリームの表示に最初の9文字を使用します。これを取得するコマンドは次のとおりです。
/usr/bin/git rev-parse --short=9 HEAD
Gitマージの問題を回避するために、最初にプロジェクトの-Info.plistファイルのビルド番号（CFBundleVersion）値を変更してビルドを実行できるようにし、最後のステップで値をデフォルトに戻すことを考えました。 1ソース管理で変更されて表示されないようにします。「スクリプトの実行」を使用して「ビルドフェーズ」フローでこれを行うためのあらゆる方法を試しましたが、最後のステップで値を元に戻すためにコードを挿入しても、実行中のアプリに影響を与えていたようです。
もう少し掘り下げた後、私はスキーマとプレアクションとポストアクションに出くわしました。これが私のルートのようでした。
したがって、スキーマでは、「ビルド」プランに対して、CFBundleVersion値を現在のコミットID（9文字）に設定するプレアクションを作成し、ポストアクションでは、この値をデフォルトに戻します。 （1）。これは必要に応じて機能するようです。
これが私のプレアクションコードです：
buildPlist="$SRCROOT/$INFOPLIST_FILE"
echo "The build plist file $buildPlist"
CFBundleVersion="$(cd $SRCROOT;/usr/bin/git rev-parse --short=9 HEAD)"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $CFBundleVersion" $buildPlist
これが私のアクション後のコードです：
buildPlist=$"$SRCROOT/$INFOPLIST_FILE"
CFBundleVersion=1
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $CFBundleVersion" $buildPlist
「ビルドフェーズ」スクリプトで使用していたものとは異なるこのコードで注意すべき点は、$SRCROOTを使用してディレクトリを設定するための要件です。当初、「ビルドフェーズ」と同じビルド設定が得られるという印象を受けましたが、そうではないようです。[スクリプトの実行]ウィンドウには、[ビルド設定の提供元：]という名前のオプションがあり、ターゲットを選択できます。たぶんそれは正しく機能していて、事前のアクションに関係なく、完全なディレクトリパスを設定する必要があります。それを理解するのに少し時間がかかったので、私はそれについて言及しようと思いました。
要約すると、私は受け取った情報に感謝し、それは私が何をしようとしていたかを考え、最終的に私が望んでいた目標に到達するのに役立ちました。
gitのような非線形開発モデルを追跡しようとしてビルド番号を線形にインクリメントすることのポイントは実際にはわかりませんが、それを達成する方法はあります。それはあなたが何を求めているかによります。「公式」ビルドのビルド番号が必要な場合は、ビルド時にビルドスクリプトを使用してこれを簡単に生成できます。次に、ビルドスクリプトに、生成された番号でビルド中のコミットにタグを付けます。このようなもの：
git checkout build-branch
generate_build_num > buildnum.txt
make
git tag `cat buildnum.txt`
一意の増分ビルド番号を生成する責任はgenerate_build_numスクリプトにあり、タグを使用することで、対応するコミットにいつでも戻ることができます。
一方、gitツリーのすべてのコミットを線形ビルド番号に対応させたい場合は、さらに多くの作業が必要になります。
私の意見では、sha1を直接使用する場合と比較して、これで得られるものはあまりありません。
すべてのビルドでInfo.plistに触れることに関連するマージの競合を回避するために、少し異なるアプローチを使用します。これは、ビルド番号を一時的に設定（およびリセット）するmagnusMTBの戦略に似ていますが、事前アクションと事後アクションを使用する代わりに、プロジェクトのInfo.plistにプレースホルダー値を残してから、「スクリプトの実行」ビルドフェーズを追加します。Xcodeプロジェクトのコピーに触れることなく、製品のビルド番号のみを変更します。
スクリプトは次のようになります。
# Grab some environment variables from Xcode
BUILD_NUMBER_FILE="${SOURCE_ROOT}/BuildNumber"
PLIST_FILE="${TARGET_BUILD_DIR}/${CONTENTS_FOLDER_PATH}/Info.plist"
# Create a build string
# Anything goes, but this uses my employer's App_vX_YYMMDD.HHMM format
majorVersion=`/usr/libexec/PlistBuddy -c "PRINT:CFBundleShortVersionString" "$PLIST_FILE"`
dateTime=`date "+%y%m%d.%H%M"`
buildNumber=App\_v$majorVersion\_$dateTime
# Write the build string to a local file under version control
echo $buildNumber > $BUILD_NUMBER_FILE
# Set the build number in the product's plist (Not the Xcode project's plist)
echo Writing generated build number \"$buildNumber\" to \"$PLIST_FILE\"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$PLIST_FILE"
このように、バージョン管理下のInfo.plistは変更されませんが、テストまたはデプロイに使用されるアプリ内のビルド番号は、動的に生成された「正しい」値です。ビルド番号は、Info.plistとは別に存在する単一のクリーンマージファイルを介してバージョン管理に残ります。
警告：ビルド番号がInfo.plistの外部のどこかでバイナリにベイクされているかどうかはわかりません。これにより問題が発生する可能性があります。ただし、その価値については、私がテストしているアプリは、バンドル内のInfo.plistから正しい（スクリプトで生成された）ビルド番号を自己報告します。