2

I have a Jenkins job that uploads my iOS app to HockeyApp. I can see this error in my logs

Error uploading to HockeyApp: {"status"=>"error", "message"=>"Bundle Version does not match. Expected value: 228 Actual value: 15"}

But the app seems to be successfully uploaded and available to download from Hockey. Could someone please explain what this error means?

I set my build number to match my Jenkins build number i.e 228 in this case. I have no idea what the Actual value of 15 refers to?

Thanks!

m.y
  • 691
  • 9
  • 21
  • Please contact HockeyApp support. If you are changing the build number in the Info.plist as part of your build process, you also should change the same in the Info.plist of the dSYM. – Kerni Mar 26 '15 at 11:22
  • @Kerri I think the problem was that Jenkins was picking up an old dSYM (bundle version 15). I now make sure that the old binaries .ipa and .dSYM get deleted before each new Jenkins build and the error has gone away. I didn't have to change the Info.plist of the dSYM in my Jenkins job shell script. – m.y Mar 31 '15 at 15:20
  • You can find an answer here: http://stackoverflow.com/questions/13323728/update-cfbundleshortversionstring-in-dsym-at-build/34536807#34536807 – Brennan Dec 30 '15 at 20:32

1 Answers1

0

I created a script that I can drop into any Xcode project folder and call from a Run Script which will update the Info.plist for the app and the dSYM so that the build number matches. It can then be uploaded to services like HockeyApp and iTunes Connect for TestFlight and the App Store.

I prefer to manage the script outside of Xcode's Run Script because I can edit it more easily and keep the contents of the project file much smaller. I can also version control the script independently of the project file.

The Build Number in this script is set with just the current date. There are other ways to generate a unique build number. One approach is covered on Jared Sinclair's blog which uses the Git hash for the latest commit. The script I am using uses a timestamp which goes down to a minute. I find it useful to know when a build was created and having the build number double as a timestamp I can see the date immediately. And for my purposes it is unique enough.

http://blog.jaredsinclair.com/post/97193356620/the-best-of-all-possible-xcode-automated-build

Gist: https://gist.github.com/brennanMKE/c4640b7a2cf39888d858

#!/bin/sh
set -e

# Purpose: Updates Info.plist for app and dSYM to a unique value for each build.

# Usage:
# Add as a Run Script in Xcode Build Phases

# UPDATE_SCRIPT=${PROJECT_DIR}/update_build_number.sh
# if [ -f ${UPDATE_SCRIPT} ]; then
#     sh ${UPDATE_SCRIPT}
# fi

BUILD_NUMBER=`date "+%Y.%m.%d.%H%M"`
APP_INFO_PLIST=${TARGET_BUILD_DIR}/${INFOPLIST_PATH}
DSYM_INFO_PLIST=${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist

if [ -f ${APP_INFO_PLIST} ]; then
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUMBER" "${APP_INFO_PLIST}"
    echo "Updated ${APP_INFO_PLIST}"
else
    echo "Could not find ${APP_INFO_PLIST}"
fi

# Only the Release Configuration creates the dSYM
if [ "${CONFIGURATION}" = 'Release' ]; then
    if [ -f ${DSYM_INFO_PLIST} ]; then
        /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUMBER" "${DSYM_INFO_PLIST}"
        echo "Updated ${DSYM_INFO_PLIST}"
    else
        echo "Could not find ${DSYM_INFO_PLIST}"
    fi  
fi
Brennan
  • 11,546
  • 16
  • 64
  • 86