Auto-incrementing build number in Xcode and multiple developers using Git - xcode

Question

I am starting up a new project that will have multiple developers working in Xcode using Git. I want to setup auto-incrementing build numbers, and I have found a few good answers on how to do this, but my concern is with the multiple developers and Git.
I know in Xcode there are some files, like the project file, that are very sensitive and hard to merge. The best techniques I have seen for auto-incrementing build numbers would be susceptible to the same multiple Git merge issue.
Is there any guidance here as to how I can use an auto-incrementing build technique and still keep the merging issues to a minimum? Maybe the answer is that there is no good answer, but I want to find out what others are doing.

Answer 1

So first a thanks to harald for his answer and comments, which helped me to better think through what I really wanted to accomplish.
Let me sum up what my thought was, what I realized I wanted to do, and how I did it.
I wanted a way to populate the build number (CFBundleVersion) in an automated way. This value is stored in the main project -Info.plist file, which is source controlled. I was concerned about following guides to automate this via "Build Phase" scripts in that it would modify this file for possibly multiple developers and cause a situation where constant merging would be needed.
The reason I wanted this is so that I could easily track down what code was in play for a particular build. While one certainly can manually do this with tagging and proper documentation, I wanted a more automated and flexible way since I think I will be done a lot of builds out to TestFlight.
My original line of thought was to use a simple incremental build number for this value, but that would really be trouble with the merging. Harald's suggestion of using the commit SHA on the Git repo sparked a better line of thinking for me.
So the first part of my solution is to use the first 9 characters from the commit SHA (the SHA would be too long). I use the first 9 characters since I am running GitLab HQ (a great open source project, by the way) and they use the first 9 in their display of the running stream of commits. The command to get me this is as follows:
/usr/bin/git rev-parse --short=9 HEAD
In order to avoid having the Git merge issue, I thought of first changing the build number (CFBundleVersion) value in the projects -Info.plist file, allowing the build to run, and then at the last step change the value back to a default 1 so that it would not appear changed in source control. I tried every which way to do this in the "Build Phases" flow using a "Run Script", but it seems that even when putting the code in to revert the value in the final step, it was affecting the running app.
After digging a bit more I came across the schemas and the pre-actions and post-actions. This seemed to be my route.
Thus, in the schema, for the "build" plan, I created a pre-action that would set the CFBundleVersion value to my current commit Id (9 characters), and in the post-action I would revert this value back to the default (1). This seems to work as I need it to.
Here is my pre-action code:
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
Here is my post-action code:
buildPlist=$"$SRCROOT/$INFOPLIST_FILE"
CFBundleVersion=1
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $CFBundleVersion" $buildPlist
Something to note with this code that differs from what I was using in the "Build Phase" scripts is the requirement to use the $SRCROOT to set the directory. Initially I was under the impression that you would get the same build settings as you do in the "Build Phase", it appears you do not. There is an option in the "Run Script" window named "Provide build settings from :" and it lets you select a target. Maybe that is working correct and regardless given the pre-action you must set your full directory path. It took me a little bit to figure that out so I thought I would mentioned it.
In summary, I appreciate the information I received and it helped me think through what I was looking to do and ultimately get to the goal I wanted.

Answer 2

While I don't really see the point of having linearly incrementing build numbers trying to track a nonlinear development model like git, there's ways to acheive it. It depends on what you're after though. If you just want a build number for "official" builds, you can quite simply generate this by the build-scripts when building. Then have the build script tag the commit being built with the generated number. Something like this:
git checkout build-branch
generate_build_num > buildnum.txt
make
git tag `cat buildnum.txt`
The responsibillity for generating a unique, incrementing build number is with the generate_build_numscript, and you can always find back to the corresponding commit by using the tag.
If on the other hand you want every commit in the git tree to correspond to a linear build number, you're in for a lot more work.
In my opinion, there's not much to gain in this compared to using the sha1 directly.

Answer 3

I use a slightly different approach for avoiding merge conflicts associated with touching the Info.plist on every build. It's similar to magnusMTB's strategy of temporarily setting (and then resetting) the build number, but instead of using pre- and post-actions I just leave a placeholder value in the project's Info.plist, and then add a "run script" build phase to modify only the product's build number without touching the Xcode project's copy.
The script looks like this:
# 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"
In this way, the Info.plist under version control remains untouched, but the build number inside the app used for testing or deployment is the "correct" dynamically generated value. The build numbers remain in version control through a single clean-merging file that lives apart from Info.plist.
Caveat: I'm not sure if the build number is baked into the binary somewhere outside Info.plist. This could create issues. However, for what it's worth, the app I'm testing with self-reports the correct (script-generated) build number from the Info.plist in its bundle.