Githawk: Build Number Auto-increment

Created on 22 Sep 2017  ยท  6Comments  ยท  Source: GitHawkApp/GitHawk

Honestly the auto-incrementing build number has always been an annoyance in team projects because every PR immediately has a conflict and while it takes two seconds to fix I'd rather not have it ๐Ÿ˜‚

Obviously this is complete personal preference but an alternative solution would be to do it based on git:

#!/bin/sh

# Retrieve git information
commitHash=$(git rev-parse --short HEAD)
commitCount=$(git rev-list HEAD --count)

if [ $CONFIGURATION = "Release" ]
then
    echo "RELEASE BUILD"
    bundleVersion=$commitCount
else
    echo "DEVELOPMENT BUILD"
    bundleVersion=$commitHash
fi

# Update Build Identifier
echo "CFBundleVersion = $bundleVersion"

if [ -f "${BUILT_PRODUCTS_DIR}/GitHawk.appex/Info.plist" ]; then
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bundleVersion" "${BUILT_PRODUCTS_DIR}/GitHawk.appex/Info.plist"
else
    echo "GitHawk not found so bundle update not applied to that plist"
    echo "- ${BUILT_PRODUCTS_DIR}/GitHawk.appex/Info.plist"
fi

So this does add another dependency (which we could/should store in the repository) but with this as a runtime script it doesn't directly alter the info.plist, it changes the one in the actual build product ultimately meaning we never see it increment and therefore no conflicts

@rnystrom Happy to close this as a non-issue if you're happy with it as is but thought I'd raise an alternative solution regardless!

โ” question

Most helpful comment

commitHash=$(git rev-parse --short HEAD) returns the 7 character hash which GitHub handles fine

All 6 comments

What's the dependency?

Also, I'd be fine changing the build # to be the first 7 of the commit hash too. Makes it easy to lookup the commit from the settings screen. Maybe even make it tappable to push a webview w/ the commit?

PlistBuddy is the dependency, used to manipulate the Info.plist after the fact.

Which having just checked we already use, so fun fact no new dependencies. So this can be as complicated or as simple as you make it, as an open-source app it might actually be nice to use the hash as it's publicly available and makes it clear what's included in the production app!

IMO let's move to hash, I think that's a neat idea. Really ties the whole open source bit together nicely! Let's use w/e is the minimum hash string we can for GitHub to link correctly.

commitHash=$(git rev-parse --short HEAD) returns the 7 character hash which GitHub handles fine

๐Ÿš€๐Ÿš€๐Ÿš€ lets do it!

Sent with GitHawk

Closing as this seems to be done and working now

Was this page helpful?
0 / 5 - 0 ratings

Related issues

viktorgardart picture viktorgardart  ยท  3Comments

weyert picture weyert  ยท  3Comments

BasThomas picture BasThomas  ยท  3Comments

rnystrom picture rnystrom  ยท  3Comments

rnystrom picture rnystrom  ยท  3Comments