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.


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:

This page contains several sub-sections:

Environment variables


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 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


The numeric identifier for the current build.

Example: 56


A unique identifier for the current build job.

Example: 564d3232d83277012014f915


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

Example: 564d3232d83277010014e926


The name of the branch currently being built.

Example: some-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


The repository slug using the owner/repo format.

Example: buddybuild/2048-App


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

Example: 526


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

Example: /Users/buddybuild/workspace


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

Example: /Users/buddybuild/secure_files


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 buddybuild API


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

Example: /tmp/build.ipa


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

Example: /tmp/build-appstore.ipa


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/


The scheme used for the current build.

Example: 2048 - Release


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.


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 script should be in the root of your repository.
#!/usr/bin/env bash

# Example: Clone Parse example project
git clone

# 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 <>
export GIT_REVISION_AUTHOR=$(git log -1 --pretty=format:"%an <%ae>")
Important 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)


See the Environment variables section if you need to access environment variables in the script.

Pre-build script

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

Add the script to your repository, next to your .xcodeproj or build.gradle files.
#!/usr/bin/env bash

# Example for adding a key to the Plist
/usr/libexec/PlistBuddy -c "Add APP_BRANCH String $BUDDYBUILD_BRANCH"
Note 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.


See the Environment variables section if you need to access environment variables in the script.

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 script to the root of your repository.
#!/usr/bin/env bash

# Example of uploading a file to your archive service
curl \
 -F "build_number=$BUDDYBUILD_BUILD_NUMBER" \
 -F "
Note 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

Another example would be to use to integrate Danger (a CI automation tool) as part of your build, so that it can apply its set of rules:
#!/usr/bin/env bash

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

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


See the Environment variables section if you need to access environment variables in the script.

Finally script

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

Add the script to the root of your repository.

Note examples

You would use this script to perform any required operations, whether your build, test execution, or deployment was successful or not. You cannot use to fail a build; it has already completed successfully by the time this script is run.

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


See the Environment variables section if you need to access environment variables in the script.

Manually fail 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

Another way to fail the build is to use set -e. This causes the shell that is running your script to exit immediately if one of the commands in the script exits with a non-zero status. If you decide to use set -e, place it before the commands that should cause an immediate exit (typically, at the top of the script). For example:

#!/usr/bin/env bash

set -e

scp .

This example tries to fetch a remote file called, and then unpacks the ZIP archive. If either command fails, they return a non-zero status and the build fails.

Upload dSYMs to Fabric

Fabric is a platform that helps mobile teams build better apps. Many developers use Fabric’s Crashlytics kit to process crash reports. In order to use Crashlytics, the debug symbols file (dSYM) file needs to be uploaded.

The dSYM file is only generated when the Strip Debug Symbols setting is enabled in Xcode, in the build settings of your project. This setting is an optimization, as symbols can add a notable amount to the size of your compiled binary, and removal makes it much harder for others to reverse engineer your code.

When Strip Debug Symbols is enabled, the symbol names of objects within your app are removed from the compiled binary, and are written to the dSYM file. The dSYM file is useful for re-symbolicating crash reports.

Fabric includes an upload-symbols script that you can call anywhere in your build process to upload your dSYMs. That script is included in Fabric’s CocoaPod payload at $PODS_ROOT/Fabric/upload-symbols.

To upload your dSYMs to Fabric:

  1. Create (or update) in the root of your repository so that it contains the following lines:

    #!/usr/bin/env bash
    echo "Uploading IPAs and dSYMs to Crashlytics"
    echo "Uploading to Fabric via command line"
    $BUDDYBUILD_WORKSPACE/Fabric.framework/upload-symbols -a $CRASHLYTICS_API_KEY -p ios "$BUDDYBUILD_PRODUCT_DIR"
  2. Commit the changes to your repository:

    git add
    git commit -m "Copy dSYMs to Crashlytics"
    git push
  3. Ensure that Build for archive is enabled in the buddybuild Dashboard for your app. If this setting is not enabled, the dSYMs directory is not created and so nothing can be uploaded to Crashlytics.

For more information, see Crashlytics' Advanced Setup.

Upload build artifacts to Amazon S3

If your builds produce assets that you’d like to use in other contexts, you need to upload those assets to some persistent storage because the buddybuild VM used to build your app is deleted upon build completion; only app binaries, test results, and logs are normally saved.

You can use the custom script to copy assets to persistent storage such as Amazon’s Simple Storage Service, or S3. The following example uses environment variables to provide your Amazon AWS credentials, and the awscli tool to perform the upload to S3.

  1. Setup the following environment variables in the buddybuild dashboard, using the appropriate values for your AWS account:

    • AWS_ACCESS_KEY_ID: your AWS access key.

    • AWS_SECRET_ACCESS_KEY: your AWS secret access key.

    • AWS_DEFAULT_REGION: defaults to us-west-2.

  2. Create (or update) in the root of your repository so that it contains the following lines:

    #!/usr/bin/env bash
    aws s3 cp my_build_asset.file s3://mybucket/

    Replace my_build_asset.file with the filename of a build artifact that you wish to copy to S3. Replace mybucket with the identifier for the destination bucket on S3. Add as many aws commands as required to copy each build artifact.

  3. Commit the changes to your repository:

    git add
    git commit -m "Copy assets to S3"
    git push

For more information, see:

Installing Swiftlint

Swiftlint is a tool to enforce Swift style and conventions. You can install it manually from a custom build step:

brew install swiftlint

If you’re running SwiftLint as part of an Xcode Run Script phase, you will need either a file or a one. For more information, see the official documentation.


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

results matching ""

    No results matching ""