Custom Build Steps

Buddybuild automatically analyzes your repository and automatically configures itself with the best build settings. However, if you require custom logic as part of your build, you can include custom scripts in your repository to run at four points during the build:

During the build, the VM is yours. This means that you can run arbitrary operations during those four points.

Note

Looking for a detailed walkthrough and common examples?

For a detailed walkthrough of how and when teams use custom build steps, and an ever growing list of examples, visit: https://www.buddybuild.com/blog/customizing-the-build-process

This page contains several sub-sections:

Environment Variables

Important

Any environment variables set by buddybuild are available to all phases of a build.

However, environment variables set by scripts invoked by your build tool, tests, or other build-related operations, are only available while those scripts are executing.

For example, the environment variable BUILT_PRODUCTS_DIR is only available while Xcode is running, specifically when a Run Script is executing.

If you need to persist environment variables across script executions, you have a few options:

  • Specify the environment variables in the buddybuild dashboard — buddybuild takes care of making those environment variables available to every step of your builds.

  • Append export commands to the .bashrc file; .bashrc is sourced every time a (subsequent) Bash script is executed. For example, within buddybuild_postclone.sh you could define environment variables like this:

    APP_VERSION=$(node -pe "require('./package.json').version")
    echo "export APP_VERSION=$APP_VERSION" >> $HOME/.bashrc

    The first line captures the version key from your repository’s package.json file using node.js. The second line appends the environment variable definition to .bashrc.

  • If you’re not using Bash, write the definitions of the environment variables to a file, and read those definitions every time your scripts execute.

Common buddybuild Variables

Variable Name Description

BUDDYBUILD_BUILD_NUMBER

The numeric identifier for the current build.

Example: 56

BUDDYBUILD_BUILD_ID

A unique identifier for the current build job.

Example: 564d3232d83277012014f915

BUDDYBUILD_APP_ID

A unique identifier for the app. Useful if you have multiple apps in the same repo.

Example: 564d3232d83277010014e926

BUDDYBUILD_BRANCH

The name of the branch currently being built.

Example: some-branch

BUDDYBUILD_BASE_BRANCH

If the current build is a pull request, this is the name of the base branch associated with the PR. Otherwise, this is the empty string ("").

Example: master

BUDDYBUILD_REPO_SLUG

The repository slug using the owner/repo format.

Example: buddybuild/2048-App

BUDDYBUILD_PULL_REQUEST

If the current build is a pull request, this is the pull request number.

Example: 526

BUDDYBUILD_WORKSPACE

This is the location of the source code on the VM.

Example: /Users/buddybuild/workspace

For Android, the build output folder is in the exact relative location as in your local environment. For example, if the build output folder is in the app folder locally, this variable is set to /Users/buddybuild/workspace/app/build.

BUDDYBUILD_SECURE_FILES

This is the location of your secure files on the VM.

Example: /Users/buddybuild/secure_files

BUDDYBUILD_TRIGGERED_BY

Indicates the condition that triggered the build.

Example: webhook

Possible values:

  • webhook:
    build is triggered by a webhook

  • webhook_pull_request_update:
    build is triggered when a pull request is updated

  • webhook_pull_request_open:
    build is triggered when a pull request is created

  • ui_triggered:
    build is triggered by the "Build Now" button

  • scheduler:
    build is triggered by schedule

  • rebuild_of_commit:
    build is triggered by the "Rebuild" button

  • api_triggered:
    build is triggered by the

    link:https://apidocs.buddybuild.com/builds/post-trigger.html[buddybuild API]

iOS-specific variables

Variable Name Description

BUDDYBUILD_IPA_PATH

Only available in post-build. Includes the filename in the path.

Example: /tmp/build.ipa

BUDDYBUILD_APP_STORE_IPA_PATH

Only available in post-build. Includes the filename in the path.

Example: /tmp/build-appstore.ipa

BUDDYBUILD_PRODUCT_DIR

This is the location of .ipa and .dsym files generated during the build. Useful if you need to apply further processing to these files.

Example: /tmp/sandbox/app/product/

BUDDYBUILD_SCHEME

The scheme used for the current build.

Example: 2048 - Release

BUDDYBUILD_TEST_DIR

This is the location of the test product folder.

Example: /tmp/sandbox/app/test

Inside you will find multiple files related to tests including Coverage.profdata.

Android-specific variables

Variable Name Description

BUDDYBUILD_APKS_DIR

This is the location of .apk files generated during the build. Useful if you need to apply further processing to these files.

Example: /tmp/sandbox/app/apks

BUDDYBUILD_VARIANTS

The list of the variants being built.

Example: release

ANDROID_HOME

The path to the Android SDK.

Example: /Users/buddybuild/.android-sdk

ANDROID_NDK_HOME

The path to the Android NDK.

Example: /Users/buddybuild/android-ndk-r10e

Note

Don’t see the information you need?

No problem! Remember, the VM is yours at each build step. For instance, you could expose git information for the build in the Post-clone script.

User-defined variables

You can also define your own environment variables through buddybuild’s dashboard. User-defined environment variables are stored securely and made available during the build.

Post-clone script

The post-clone script runs immediately after git clone, before buddybuild does any analysis of what is in the repository.

The buddybuild_postclone.sh script should be in the root of your repository.

buddybuild_postclone.sh
#!/usr/bin/env bash

# Example: Clone Parse example project
git clone https://github.com/example/ParseCloudCode

# Example: Expose the commit SHA accessible through $GIT_REVISION_SHA
# Environment Variable
export GIT_REVISION_SHA=$(git rev-parse HEAD)

# Example: Expose the commit author & email through the $GIT_REVISION_AUTHOR
# in the following format: Author Name <author@example.com>
export GIT_REVISION_AUTHOR=$(git log -1 --pretty=format:"%an <%ae>")
Important

buddybuild_postclone.sh examples

Some things you might want to do in a post-clone step:

  • Clone other git repositories (e.g. another repository contains your Parse cloud code)

  • Generate or modify your Xcode project (e.g. some React Native and Cordova projects require this).

  • Expose git information (e.g. the author or the commit SHA for the build)

Pre-build script

The pre-build script runs before the build, but after buddybuild has automatically installed dependencies (eg. Cocoapods, Carthage, etc.).

Add the buddybuild_prebuild.sh script to your repository, next to your .xcodeproj or build.gradle files.

buddybuild_prebuild.sh
#!/usr/bin/env bash

# Example for adding a key to the Plist
/usr/libexec/PlistBuddy -c "Add APP_BRANCH String $BUDDYBUILD_BRANCH"
Note

buddybuild_prebuild.sh examples

You might want to use a custom pre-build step if you need to do some extra dependency compilation, or add something custom to your plist.

While you can use this to populate API keys or credentials, you can also access device keys that you’ve added on the dashboard through the BuddyBuildSDK without doing any custom build steps.

Post-build script

The post-build script runs after a successful build (if the build fails, for any reason, the post-build script does not run).

Add the buddybuild_postbuild.sh script to your repository, next to your .xcodeproj or build.gradle files.

buddybuild_postbuild.sh
#!/usr/bin/env bash

# Example of uploading a file to your archive service
curl \
 -F "file=@$BUDDYBUILD_IPA_PATH" \
 -F "build_number=$BUDDYBUILD_BUILD_NUMBER" \
 -F "https://archiveservice.example.com
Note

buddybuild_postbuild.sh examples

Typically, you would use this script to upload specific artifacts to various service integrations you might have.

  • If you want to archive the .ipa / .dSYM files for yourself

  • Sending build artifacts to another service

If the post-build step is not running for you, please check that you have code signing set up.

Finally script

The finally script runs last, after the build, tests, and any deployment operations.

Add the buddybuild_finally.sh script to the root of your repository.

buddybuild_finally.sh
#!/usr/bin/env bash

bundle install
bundle exec danger --fail-on-errors=true
Note

buddybuild_finally.sh examples

You would use this script to perform any required operations, whether your build, test execution, or deployment was successful or not.

One example would be to use buddybuild_finally.sh to integrate Danger (a CI automation tool) as part of your build, so that it can apply its set of rules whether the build succeeds or fails. See our blog post "Using Danger with buddybuild" for details.

It is also your last opportunity to upload any build artifacts to any service integrations that you may have; once buddybuild_finally.sh completes, the build VM is destroyed.

Manually failing the build from a custom build step

When some conditions required for your build to be successful are not met, you may want to manually fail the build. To do that, exit from your script with a non-zero status code. That is how buddybuild knows that the build must fail.

#!/usr/bin/env bash

if [[ "$BUDDYBUILD_BRANCH" =~ "release" ]]; then
  echo "This script should only be used on release branch!"
  echo "Aborting build"

  exit 1
fi

Support

As with everything, if you need help with anything, please get in touch via Intercom or email support@buddybuild.com and we will find the best way to solve your problem.

results matching ""

    No results matching ""