Automated Version Numbering with Git

As a mobile developer, I always wanted to explore on how to better managed my build / revision version numbering especially, when it comes to beta testing stage.

During this stage, feedback flows in and critical patches and fixes are released back to the beta tester. Usually this is also coupled with release notes and the build number. To put this short, it’s a struggle to do that process every time.

Then, that question flashes! Wouldn’t be easier to have something that automatically bump up your version number / or build number every time you do your git push or commit.

Today, I’m gonna share with you how I automatically – bump up my AndroidManifest.xml versionCode and Info.plist BuildNumber whenever, I do a git commit.

This tutorial sections is divided into two sections.

  • Shell script to bump build number in AndroidManifest.xml and Info.plist
  • Triggering the script using Git Hooks

 

Shell script to bump up build number

Below is a shell script, that will open up AndroidManifest.xml find the xml attribute versionCode and then increment it by 1. Some goes for Info.plist, it will find a custom property within the Plist named BuildNumber and does the same thing. For this example, I named mine as BuildNumber you can named and associate it with other name like RevisionNumber etc.

Now, to do this, in iOS xCode project open up the info.plist, click on the Source Tab, this should bring up a plist editor.

Create a new “custom property” , named it BuildNumber which is a string and the value is 1. For Android project, since versionCode can be used to do the same thing we just make sure the versionCode is to the value of 1.

plist

Custom Property – Plist Editor

# AndroidManifest.xml
# Change Path to in MANIFEST
MANIFEST="{YOUR ANDROID PROJECT FOLDER}/Properties/AndroidManifest.xml"
declare -x SCRIPTPATH="${0}"
FULLPATH=${SCRIPTPATH%/*}/$MANIFEST
 
if [ -f $FULLPATH ]
then
	LINE=$(grep -o ${FULLPATH} -e 'android:versionCode="[0-9]*"');
	declare -a LINE;
	LINE=(`echo $LINE | tr "\"" " "`);
	VERSION=(${LINE[1]});
	INCREMENTED=$(($VERSION+1))
	sed "s/android:versionCode=\"[0-9]*\"/android:versionCode=\"${INCREMENTED}\"/" $FULLPATH > $FULLPATH.tmp && mv $FULLPATH.tmp $FULLPATH
	echo "Updated AndroidManifest.xml versionCode to ${INCREMENTED} ...";
fi;
 
 
# Info.Plist
# Change Path to in TARGET
TARGET="{YOUR IOS PROJECT FOLDER}/Info.plist"
if [ ! -f "$TARGET" ]; then
   echo "missing file $TARGET"
   exit 1;
fi
 
buildNumber=$(/usr/libexec/PlistBuddy -c "Print BuildNumber" "$TARGET")
buildNumber=$(($buildNumber + 1))
echo "Updated Info.plist BuildNumber to ${buildNumber} ..."
/usr/libexec/PlistBuddy -c "Set :BuildNumber $buildNumber" "$TARGET"

I call this file exec-hook.sh , which is actually a batch file that will do all the automated version bumping as mentioned above. Next, we need to test it. If this file is newly created using an editor. You will need to grant it permission to execute. Open up the terminal and locate exec-hook.sh then use the following command

chmod u+x exec-hook.sh

You can test whether is working by executing it like this…

./exec-hook.sh

If the console is displaying message like Updated blah blah ..etc etc means this is working. Take note: you might need to modify the relative folder path to the location of plist and manifest xml file. Try to always use relative folder path, as you want this to work in any folder name given regardless of project.

Some IDE support custom shell script. You can actually use this script with pre-build custom script instead of opting to use Git hooks. Is entirely up to you as this shell script is independent by itself.

 

Triggering the script using Git Hooks

This is the next step. For every git project folder you cloned, comes with the hidden .git folder. Within this folder there’s a folder called hooks. They are just files that will trigger shell script once, a git operation event is fired e.g.

  • pre-commit – will fire when the user is about to commit into the local repo.
  • post-commit – happened after files are commited
  • pre-push – will fire when updates are pushed to the server.
  • post-push – fires after the push happens.

And the content of these files is rather simple, the exact “PATH to the trigger the .sh file”. Yup, simple as that.

my pre-push file content looks like this

# run my special hooks
echo "Running Pre-Commit Hook..."
./exec-hook.sh

Which is to locate the root’s folder’s file exec-hook.sh and fire it. If for some reason this command did not trigger, it is normally due to permission you will also need to grant permission to the git hook files e.g. pre-push (use chmod +x pre-push).

The only cons I see for far is that, the manifest and plist file is always changing and they will always marked as changed even thought you have pushed twice which didn’t bother me that much.
 

Comments

comments