Skip to content

Latest commit

 

History

History
90 lines (74 loc) · 6.07 KB

RELEASE_BUILDS.md

File metadata and controls

90 lines (74 loc) · 6.07 KB

This file walks us through on how we can generate release builds that we can upload to Play store/App store.

Obvious way

  • Get code merged to master branch following contributing guidelines
  • Subscribe to slack channel #connectme_build
  • Get a login credential to hockeyapp.net. Ask a contributor to get access to hockeyapp.net

That's it. As soon as we have our code merged to master. We should have a release build generated by our build servers and uploaded to hockeyapp.net

Few common problems in build generation from master

Could not upload binary to App Store Connect. Check out the error above

We get this error because we tried to upload to App Store, and app store already had a binary from us which was approved and had same version number. App store might already have 1.0.67-001, and we might be uploading 1.0.67-002. Even though full version number is different, apple still does not allow us to upload binary. So, when we receive this error from our build server, then follow following steps to fix this error

  • Create a branch from master, for example: fix-ios-build-error
  • Open following files and increment build number by 1. Change 1.0.67 -> 1.0.68
- android/app/build.gradle
- ios/ConnectMe-tvOS/Info.plist
- ios/ConnectMe-tvOSTests/Info.plist
- ios/ConnectMe/Info.plist
- ios/ConnectMeTests/Info.plist
  • Push to branch that we created from master i.e. fix-ios-build-error
  • Raise a PR to master
  • Once this PR is merged to master, above build issue will be fixed

Build failed on build server

Sometimes, we might get build failures that we don't know about. So, we need to look inside build server and check logs of build server on why our build failing. There are different strategies on finding out the issue with build server builds. Here are some steps that can be done to identify build issue.

  • Check build server logs by going to build in gitlab.corp.evernym.com git repository. Then on left side of gitlab panel, we can CI/CD section, go to Jobs
  • Find your branch name for which build failed
  • Click on Job number and we can see server detailed logs on why build failed
  • If we are not able to figure out the reason for failing builds, then we can try to generate a release build locally by steps described below
  • If release builds are working fine on local machine, and not on build server. Try matching the software versions of all dependencies on build server and local machine
  • If all dependencies are exact same, then take help from TE team and some other team memebers

Non-obvious ways

Create a release build for ios

  • yarn pod:install
  • To get the beta release certificates do bundle exec fastlane match adhoc
  • You'll be prompted to enter 2 passwords. Slack a contributor for what those are.
  • Make sure that the ios/ConnectMe/Info.plist, ios/ConnectMeTests/Info.plist, ios/ConnectMe-tvOS/Info.plist, ios/ConnectMe-tvOSTests/Info.plist, have their CFBundleVersion set to the NEXT build number
  • Make sure that the ios/ConnectMe.xcodeproj/project.pbxproj has it's 2 CURRENT_PROJECT_VERSION attributes set to the NEXT build number
  • To get releasable .ipa launch Xcode and open the ios/ConnectMe.xcworkspace project
  • Select the "Generic iOS Device"
  • Then run Product -> Archive
  • After it is done then login to hockeyapp.net and click on QA ConnectMe and then click add version button and upload it

For android local Release build

  • add my_keystore.jks file to ~/keystores folder If you get this error during the bitrise run android build then you are missing the my_keystore.jks file What went wrong: Execution failed for task ':app:validateSigningRelease'.

Keystore file /Users/norm/keystores/my_keystore.jks not found for signing config 'release'.

  • ask your team members for .bitrise.secrets.yml file and place it in directory with bitrise.yml file
  • run brew install bitrise && bitrise setup
  • Make sure that the android/app/build.gradle has it's versionCode attribute set to the PREVIOUS build number (be aware that a failed "bitrise run android" will STILL increment the number and so you will need to decrement it back to the PREVIOUS build number after a failure)
  • run bitrise run android
  • If you get this error then rm -rf node_modules and re-run bitrise run android What went wrong: Failed to capture snapshot of input files for task ':app:bundleReleaseJsAndAssets' property '$1' during up-to-date check.

Could not list contents of '/Users/norm/forge/work/code/evernym/ConnectMe/node_modules/jest-runtime/node_modules/babel-core/node_modules/.bin/babylon'. Couldn't follow symbolic link.

  • run brew install maven
  • download the vcx.aar file
  • later run mvn install:install-file -Dfile=com.evernym-vcx_1.0.0-12-06-2018T16-17_x86-armv7-release.aar -DgroupId=com.evernym -DartifactId=vcx -Dversion=1.0.0-12-06-2018T16-17 -Dpackaging=aar
  • remember to change file names as required in the above mvn install command

Understand how builds are organized in hockeyapp

As soon as we have a build success notification from our build server in slack channel, builds (.apk & .ipa) are uploaded to hockeyapp.net. There is a pattern in which we are organizing builds on hockeyapp. Here are the mappings of hockeyapp to builds generated by our build server.

  • If a build was generated from master branch, then
    • android build is uploaded to QA MeConnect Android
    • ios build is uploaded to QA ConnectMe
  • If a build was generated from any branch other than master, stable, & stage, then
    • android build is uploaded to Dev MeConnect Android
    • ios build is uploaded to ConnectMe

Builds inside Dev MeConnect Android have different way of versioning. Builds are named as 1.0.67-3341513, 1.0.67-3341512, 1.0.67-3341511, 1.0.67-3341510. If we squint a little bit in version number, we will notice that we are changing last two digits and everything else is same. That is because we are generating different apks for different ABIs of android. Below is mapping of build number to ABI

13 -> x86_64
12 -> arm64
11 -> arm7
10 -> x86

Most (95%) android devices should be able to run dev builds ending in 12.