Build Number

gistfile1.sh

#
# Set the build number to the current git commit count.
# If we're using the Dev scheme, then we'll suffix the build
# number with the current branch name, to make collisions
# far less likely across feature branches.
# Based on: http://w3facility.info/question/how-do-i-force-xcode-to-rebuild-the-info-plist-file-in-my-project-every-time-i-build-the-project/
#
git=`sh /etc/profile; which git`
appBuild=`"$git" rev-list --all |wc -l`
if [ $CONFIGURATION = "Debug" ]; then
branchName=`"$git" rev-parse --abbrev-ref HEAD`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $appBuild-$branchName" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
else
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $appBuild" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
fi
echo "Updated ${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

This contains minor fix to the script found at Jared Sinclair's blog.

That script failed if the git path had a space (e.g. when renaming Xcode), and wasn’t using that git path for branchName.

Neat!

I had an issue with HockeyApp though, when trying to upload an ipa and dSYM pair I got back an unexpected build number error.

Looking into the dSYM Info.plist I actually confirmed that the CFBundleVersion number was the one in the project's Info.plist rather than the automatically generated one.

I've fixed it by updating the dSYM info dictionary as well, like this:

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $appBuild" "${DWARF_DSYM_FOLDER_PATH}/${WRAPPER_NAME}.dSYM/Contents/Info.plist"

@johankool does it make sense? Is there a better combo of values to use? I don't like that Contents/Info.plist hanging there, but I couldn't find better build parameters.

Thank 🍻

Just in case you were wondering how to get commit hash from commit index number it will do:
git rev-list --skip=$((git rev-list --count HEAD-COMMIT_INDEX_NUMBER-1)) HEAD | head -1

@wczekaiski cool

I just had this issue, the build number generated by my machine is different from the one generated by a team mate. My commit number is also different from the commit number shown on GitHub.

I had some troubles with the generated number and looked better at the documentation of git rev-list. The --all option pretend[s] as if all the refs in refs/ are listed on the command line as . This, I assume, means that all the commit I have in branches that are not merged into master will be counted as well.

A better command would be git rev-list HEAD --count, which is what @wczekalski is using, and also faster to execute.

Thoughts?