├── .gitignore ├── README.md ├── contribution └── recipe-template.md └── recipes ├── android-ci-workflow.md ├── android-deploy-to-appcenter.md ├── android-deploy-to-bitrise.md ├── android-deploy-to-firebase.md ├── android-deploy-to-google-play.md ├── android-emulator-test.md ├── android-key-cache-build-tasks.md ├── android-key-cache.md ├── android-lint.md ├── android-nightly-workflow.md ├── android-parallel-testing-unit-test-shards.md ├── android-parallel-testing-unit-test-shards.png ├── android-parallel-ui-tests-on-multiple-devices.md ├── android-parallel-ui-tests-on-multiple-devices.png ├── android-parallel-unit-and-ui-tests.md ├── android-parallel-unit-and-ui-tests.png ├── android-pull-request-workflow.md ├── android-release-workflow.md ├── android-unit-test.md ├── android-virtual-device-tests.md ├── flutter-dart-analyzer.md ├── flutter-install-flutter-sdk.md ├── flutter-key-cache.md ├── flutter-test.md ├── github-pull-request-build-qr-code.md ├── gradle-build-profiling.md ├── ios-ci-workflow.md ├── ios-deploy-to-appcenter.md ├── ios-deploy-to-appstore.md ├── ios-deploy-to-bitrise.md ├── ios-deploy-to-firebase.md ├── ios-device-testing.md ├── ios-install-carthage-dependencies.md ├── ios-install-cocoapods-dependencies.md ├── ios-key-cache-carthage.md ├── ios-key-cache-cocoapods.md ├── ios-key-cache-spm.md ├── ios-merging-test-results-and-deploying-to-the-test-reports-add-on.md ├── ios-merging-test-results-and-deploying-to-the-test-reports-add-on.png ├── ios-nightly-workflow.md ├── ios-pull-request-workflow.md ├── ios-release-workflow.md ├── ios-run-test-groups-in-parallel.md ├── ios-run-test-groups-in-parallel.png ├── ios-run-tests-in-parallel-on-multiple-simulators.md ├── ios-run-tests-in-parallel-on-multiple-simulators.png ├── ios-simulator-test.md ├── key-cache-advanced.md ├── recipes.yml ├── rn-expo-turtle-build.md ├── rn-install-dependencies.md ├── rn-key-cache-dependencies.md ├── rn-tests.md ├── run-step-conditionally.md ├── shallow-clone-repo.md ├── slack-send-build-status.md ├── slack-send-qr-code.md ├── ssh-and-clone.md ├── start-builds.md └── workflow-create-gitflow-release-branch.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Workflow Recipes 2 | 3 | Workflow Recipes provide ready-made solutions for common Workflow tasks. Here you will find a range of different Recipes along with examples of entire Workflows. 4 | 5 | ## Using Recipes 6 | 7 | You can use Workflow Recipes in two ways: 8 | 9 | * By adding the Steps into your Workflow via the Workflow Editor 10 | * By copy-pasting the `bitrise.yml` snippet into your [app's `bitrise.yml` file](https://devcenter.bitrise.io/en/builds/configuring-build-settings/managing-an-app-s-bitrise-yml-file.html) 11 | 12 | ### Adding Steps via the Workflow Editor 13 | 14 | All you need to do here is follow the step-by-step instructions in the Recipe. 15 | 16 | ![workflow_recepies_ui](https://github.com/user-attachments/assets/6adaec87-05d9-4c1d-b66a-4fc50a882729) 17 | 18 | ### Copy-pasting the bitrise.yml snippet 19 | 20 | You can also simply copy-paste the snippet to your `bitrise.yml` file directly. Don't forget to: 21 | 22 | 1. Check the formatting of the copy-pasted YAML 23 | 2. Read the instructions as they may contain some important information on configuration 24 | 3. Check and customize the input variables 25 | 26 | ![workflow_recepies_yml](https://github.com/user-attachments/assets/7ad5f751-62f4-4520-b4c9-df1c544d4699) 27 | 28 | ## Please Share your Feedback 29 | 30 | **Workflow Recipes** is currently an MVP feature, and we’d love to hear your feedback on it. Share your thoughts on Workflow Recipes by filling out our feedback survey below (~3-5min). 31 | 32 | ### [Fill out the Feedback Survey](https://docs.google.com/forms/d/e/1FAIpQLSfBQZCB02uOMsjp1kTLJ9Bv2tm0o39w4ez638m3y3kN5KQH_w/viewform?usp=sf_link) 33 | 34 |    35 | 36 | ## The Recipes 37 | 38 | ### Cloning & Setup 39 | 40 | * [Cloning the Repository](recipes/ssh-and-clone.md) 41 | * [(Flutter) Install Flutter SDK](recipes/flutter-install-flutter-sdk.md) 42 | 43 | ### Dependencies 44 | 45 | * [(iOS) Install CocoaPods Dependencies](recipes/ios-install-cocoapods-dependencies.md) 46 | * [(iOS) Install Carthage Dependencies](recipes/ios-install-carthage-dependencies.md) 47 | * [(React Native) Install Dependencies](recipes/rn-install-dependencies.md) 48 | 49 | ### Testing 50 | 51 | * [(iOS) Run Tests on Simulator](recipes/ios-simulator-test.md) 52 | * [(iOS) Run Tests on a Physical Device](recipes/ios-device-testing.md) 53 | * [(Android) Run Unit Tests](recipes/android-unit-test.md) 54 | * [(Android) Run UI / Instrumentation Tests on Virtual Device](recipes/android-virtual-device-tests.md) 55 | * [(Android) Run UI / Instrumentation Tests on Local Emulator](recipes/android-emulator-test.md) 56 | * [(React Native) Run Tests](recipes/rn-tests.md) 57 | * [(Flutter) Run Tests](recipes/flutter-test.md) 58 | 59 | ### Building 60 | 61 | * [(React Native) Expo: Build using Turtle CLI](recipes/rn-expo-turtle-build.md) 62 | 63 | ### Linting 64 | 65 | * [(Android) Run Lint](recipes/android-lint.md) 66 | * [(Flutter) Run Dart Analyzer](recipes/flutter-dart-analyzer.md) 67 | 68 | ### Deploying 69 | 70 | * [(iOS) Deploy to App Store Connect / TestFlight](recipes/ios-deploy-to-appstore.md) 71 | * [(Android) Deploy to Google Play (Internal, Alpha, Beta, Production)](recipes/android-deploy-to-google-play.md) 72 | * [(iOS) Deploy to Bitrise.io](recipes/ios-deploy-to-bitrise.md) 73 | * [(Android) Deploy to Bitrise.io](recipes/android-deploy-to-bitrise.md) 74 | * [(iOS) Deploy to Firebase App Distribution](recipes/ios-deploy-to-firebase.md) 75 | * [(Android) Deploy to Firebase App Distribution](recipes/android-deploy-to-firebase.md) 76 | * [(iOS) Deploy to Visual Studio App Center](recipes/ios-deploy-to-appcenter.md) 77 | * [(Android) Deploy to Visual Studio App Center](recipes/android-deploy-to-appcenter.md) 78 | 79 | ### Notifications 80 | 81 | * [Slack - Send Build Status](recipes/slack-send-build-status.md) 82 | * [Slack - Send the Build QR Code](recipes/slack-send-qr-code.md) 83 | * [GitHub Pull Request - Send the Build QR Code](recipes/github-pull-request-build-qr-code.md) 84 | 85 | ### 🆕 Caching 86 | 87 | * [(iOS) Cache Swift Package Manager (SPM) dependencies](recipes/ios-key-cache-spm.md) 88 | * [(iOS) Cache CocoaPods dependencies](recipes/ios-key-cache-cocoapods.md) 89 | * [(iOS) Cache Carthage dependencies](recipes/ios-key-cache-carthage.md) 90 | * [(Android) Cache Gradle dependencies](recipes/android-key-cache.md) 91 | * [(Android) Cache Gradle build tasks](recipes/android-key-cache-build-tasks.md) 92 | * [(Flutter) Cache Dart dependencies](recipes/flutter-key-cache.md) 93 | * [(React Native) Cache NPM dependencies](recipes/rn-key-cache-dependencies.md) 94 | * [Advanced key-based caching recipes](recipes/key-cache-advanced.md) 95 | 96 | ### Optimisation 97 | 98 | * [Shallow Clone the git Repo](recipes/shallow-clone-repo.md) 99 | * [(Android) Turn on Gradle build profiling](recipes/gradle-build-profiling.md) 100 | 101 | ### Running Steps & Workflows 102 | 103 | * [Run a Step Conditionally](recipes/run-step-conditionally.md) 104 | * [Start (Parallel) Builds from the Workflow](recipes/start-builds.md) 105 | 106 | 107 | ## Example Workflows 108 | 109 | ### iOS 110 | 111 | * [(iOS) Pull Request](recipes/ios-pull-request-workflow.md) 112 | * [(iOS) CI](recipes/ios-ci-workflow.md) 113 | * [(iOS) Nightly](recipes/ios-nightly-workflow.md) 114 | * [(iOS) Release](recipes/ios-release-workflow.md) 115 | 116 | ### Android 117 | 118 | * [(Android) Pull Request](recipes/android-pull-request-workflow.md) 119 | * [(Android) CI](recipes/android-ci-workflow.md) 120 | * [(Android) Nightly](recipes/android-nightly-workflow.md) 121 | * [(Android) Release](recipes/android-release-workflow.md) 122 | 123 | ### Other 124 | * [Create Gitflow release branch](recipes/workflow-create-gitflow-release-branch.md) 125 | 126 | ## Example Pipelines 127 | 128 | ### iOS 129 | 130 | * [(iOS) Run tests in parallel on multiple simulators](./recipes/ios-run-tests-in-parallel-on-multiple-simulators.md) 131 | * [(iOS) Run test groups in parallel](./recipes/ios-run-test-groups-in-parallel.md) 132 | * [(iOS) Merging test results and deploying to the Test Reports add-on](./recipes/ios-merging-test-results-and-deploying-to-the-test-reports-add-on.md) 133 | 134 | ### Android 135 | 136 | * [(Android) Parallel testing of unit test shards by module](recipes/android-parallel-testing-unit-test-shards.md) 137 | * [(Android) Parallel UI tests on multiple devices](recipes/android-parallel-ui-tests-on-multiple-devices.md) 138 | * [(Android) Parallel unit and UI tests](recipes/android-parallel-unit-and-ui-tests.md) 139 | -------------------------------------------------------------------------------- /contribution/recipe-template.md: -------------------------------------------------------------------------------- 1 | # [Name of the recipe] 2 | 3 | ## Description 4 | 5 | [Description] 6 | 7 | ## Prerequisites 8 | 9 | 1. ... 10 | 11 | ## Instructions 12 | 13 | 1. ... 14 | - ... 15 | - ... 16 | - ... 17 | 18 | ## bitrise.yml 19 | 20 | ```yaml 21 | code 22 | ``` 23 | -------------------------------------------------------------------------------- /recipes/android-ci-workflow.md: -------------------------------------------------------------------------------- 1 | # (Android) Example CI Workflow 2 | 3 | ## Description 4 | 5 | Example Workflow for commits on the main branch of an Android app. The workflow contains: 6 | 7 | 1. [Running unit tests](/recipes/android-unit-test.md) 8 | 2. [Running UI tests on a virtual device](/recipes/android-virtual-device-tests.md) 9 | 3. [Running lint](/recipes/android-lint.md) 10 | 4. Building a test app 11 | 5. [Sending a Slack notification with the build status](/recipes/slack-send-build-status.md) 12 | 13 | ## Instructions 14 | 15 | Use the yaml below and change the following env var values to match your project settings: 16 | - `$PROJECT_LOCATION` 17 | - `$MODULE` 18 | - `$VARIANT` 19 | - `$SLACK_WEBHOOK` 20 | 21 | ## bitrise.yml 22 | 23 | ```yaml 24 | --- 25 | format_version: '17' 26 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 27 | project_type: android 28 | 29 | meta: 30 | bitrise.io: 31 | stack: linux-docker-android-22.04 32 | machine_type_id: standard 33 | 34 | workflows: 35 | ci: 36 | steps: 37 | - activate-ssh-key@4: 38 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 39 | - git-clone@8: {} 40 | - restore-gradle-cache@1: {} 41 | - android-unit-test@1: 42 | inputs: 43 | - project_location: $PROJECT_LOCATION 44 | - variant: $VARIANT 45 | - android-build-for-ui-testing@0: 46 | inputs: 47 | - variant: $VARIANT 48 | - module: $MODULE 49 | - virtual-device-testing-for-android@1: 50 | inputs: 51 | - test_devices: NexusLowRes,30,en,portrait 52 | - test_type: instrumentation 53 | - android-lint@0: 54 | inputs: 55 | - variant: $VARIANT 56 | - android-build@1: 57 | inputs: 58 | - project_location: $PROJECT_LOCATION 59 | - module: $MODULE 60 | - variant: $VARIANT 61 | - deploy-to-bitrise-io@2: {} 62 | - slack@4: 63 | inputs: 64 | - channel: "#build-notifications" 65 | - webhook_url: $SLACK_WEBHOOK 66 | - save-gradle-cache@1: {} 67 | 68 | app: 69 | envs: 70 | - PROJECT_LOCATION: "." 71 | opts: 72 | is_expand: false 73 | - MODULE: app 74 | opts: 75 | is_expand: false 76 | - VARIANT: debug 77 | opts: 78 | is_expand: false 79 | 80 | trigger_map: 81 | - push_branch: main 82 | workflow: ci 83 | ``` 84 | -------------------------------------------------------------------------------- /recipes/android-deploy-to-appcenter.md: -------------------------------------------------------------------------------- 1 | # (Android) Deploy to Visual Studio App Center 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via Visual Studio App Center. 6 | 7 | ## Prerequisites 8 | 9 | 1. An existing [Visual Studio App Center](https://docs.microsoft.com/en-us/appcenter/dashboard/) project where your app is registered. 10 | 2. Adding the API token as a [Secret](https://devcenter.bitrise.io/en/builds/secrets.html) to your Bitrise app with the name `APPCENTER_API_TOKEN`. 11 | 3. If you want to deploy a release build, don't forget to [set up code signing on Bitrise](https://devcenter.bitrise.io/en/code-signing/android-code-signing.html) to build and sign the APK with your release key. 12 | 13 | ## Instructions 14 | 15 | 1. Add the [Android Build](https://bitrise.io/integrations/steps/android-build) Step and set the following inputs: 16 | - **Build type**: Set this to `apk`. 17 | - **Variant**: Use `release`, `debug`, or one of your custom variants if you have any. 18 | 2. If you build a release variant, add the [Android Sign](https://bitrise.io/integrations/steps/sign-apk) Step. You can skip this if you plan to deploy an unsigned debug variant. 19 | 3. Add the [AppCenter Android Deploy](https://www.bitrise.io/integrations/steps/appcenter-deploy-android) step and set the following inputs: 20 | - **API Token**: `$APPCENTER_API_TOKEN` 21 | - **Owner name**: For example, `my-company`. 22 | - **App name**: For example, `my-app`. Use the [App Center CLI](https://github.com/Microsoft/appcenter-cli) to get the app name since it might not be the same as the one you can see on the Visual Studio App Center website. 23 | - Check out other options in the Step documentation or in the Workflow Editor. 24 | 25 | ## bitrise.yml 26 | 27 | ```yaml 28 | - android-build@1: 29 | inputs: 30 | - variant: release 31 | - build_type: apk 32 | - sign-apk@1: {} 33 | - appcenter-deploy-android@2: 34 | inputs: 35 | - owner_name: my-company 36 | - app_name: my-app 37 | - app_path: $BITRISE_APK_PATH 38 | - api_token: $APPCENTER_API_TOKEN 39 | ``` 40 | -------------------------------------------------------------------------------- /recipes/android-deploy-to-bitrise.md: -------------------------------------------------------------------------------- 1 | # (Android) Deploy to Bitrise.io 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via the [Bitrise.io Ship add-on](https://devcenter.bitrise.io/en/deploying/deploying-with-ship/getting-started-with-ship.html). 6 | 7 | ## Prerequisites 8 | 9 | * If you want to deploy a release build, don't forget to [set up code signing on Bitrise](https://devcenter.bitrise.io/en/code-signing/android-code-signing.html) to build and sign the APK with your release key. 10 | 11 | ## Instructions 12 | 13 | 1. Add the [Android Build](https://bitrise.io/integrations/steps/android-build) Step and set the following inputs: 14 | - **Build type**: Set this to `apk`. 15 | - **Variant**: Use `release`, `debug`, or one of your custom variants if you have any. 16 | 2. If you build a release variant, add the [Android Sign](https://bitrise.io/integrations/steps/sign-apk) Step. You can skip this if you plan to deploy an unsigned debug variant. 17 | 3. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step. 18 | 19 | ## bitrise.yml 20 | 21 | ```yaml 22 | - android-build@1: 23 | inputs: 24 | - variant: release 25 | - build_type: apk 26 | - sign-apk@1: {} 27 | - deploy-to-bitrise-io@2: {} 28 | ``` 29 | -------------------------------------------------------------------------------- /recipes/android-deploy-to-firebase.md: -------------------------------------------------------------------------------- 1 | # (Android) Deploy to Firebase App Distribution 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via Firebase App Distribution. 6 | 7 | This example builds and deploys an APK, but the workflow can be tweaked to distribute AAB instead. 8 | 9 | ## Prerequisites 10 | 11 | * An existing Firebase project where your exact package name is registered. See the [Firebase documentation](https://firebase.google.com/docs/app-distribution/android/distribute-console?apptype=apk) for details. 12 | * Obtain a token from Firebase by running `firebase login:ci` locally. See the [Firebase CLI](https://firebase.google.com/docs/cli#sign-in-test-cli) docs for details. 13 | * Add this token as a [Secret](https://devcenter.bitrise.io/en/builds/secrets.html) to your Bitrise app with the name `FIREBASE_TOKEN`. 14 | * Get your Firebase App ID from your project's General Settings page and pass this value as an input to the `firebase-app-distribution` step. 15 | * If you want to deploy a release build, don't forget to [set up code signing on Bitrise](https://devcenter.bitrise.io/en/code-signing/android-code-signing.html) to build and sign the APK with your release key. 16 | 17 | ## Instructions 18 | 19 | 1. Add the [Android Build](https://bitrise.io/integrations/steps/android-build) Step and set the following inputs: 20 | - **Build type**: Set this to `apk`. 21 | - **Variant**: Use `release`, `debug`, or one of your custom variants if you have any. 22 | 2. If you build a release variant, add the [Android Sign](https://bitrise.io/integrations/steps/sign-apk) Step. You can skip this if you plan to deploy an unsigned debug variant. 23 | 3. Add the [Firebase App Distribution](https://bitrise.io/integrations/steps/firebase-app-distribution) step and set the following inputs: 24 | * Firebase token: use the secret env var previously defined: `$FIREBASE_TOKEN` 25 | * App path: this should point to the APK that the previous steps have built and signed. By default, it's located at `$BITRISE_DEPLOY_DIR/app-release-bitrise-signed.apk`, but the exact file name might be different based on your project config. 26 | * Firebase App ID: see the Prerequisites section above for details 27 | * Optional: you can define test groups or individual testers in the step inputs 28 | 29 | ## bitrise.yml 30 | 31 | ```yaml 32 | - android-build@1: 33 | inputs: 34 | - variant: release 35 | - build_type: apk 36 | - sign-apk@1: {} 37 | - firebase-app-distribution@0: 38 | inputs: 39 | - firebase_token: $FIREBASE_TOKEN 40 | - app_path: $BITRISE_DEPLOY_DIR/app-release-bitrise-signed.apk 41 | - app: your_app_id_from_firebase 42 | - testers: email@company.com # optional 43 | - groups: qa-team #optional 44 | ``` 45 | -------------------------------------------------------------------------------- /recipes/android-deploy-to-google-play.md: -------------------------------------------------------------------------------- 1 | # (Android) Deploy to Google Play (Internal, Alpha, Beta, Production) 2 | 3 | ## Description 4 | 5 | Building the app and uploading to Google Play to internal, alpha, beta or production track. 6 | 7 | ## Prerequisites 8 | 9 | 1. An Android keystore file is uploaded to Bitrise. For details, see [Android code signing using the Android Sign Step](https://devcenter.bitrise.io/en/code-signing/android-code-signing/android-code-signing-using-the-android-sign-step.html). 10 | 2. Google Play API Access is set up. For details, see [Deploying Android apps to Bitrise and Google Play](https://devcenter.bitrise.io/en/deploying/android-deployment/deploying-android-apps-to-bitrise-and-google-play.html#setting-up-google-play-api-access). 11 | 12 | ## Instructions 13 | 14 | 1. (Optional) Add the [Change Android versionCode and versionName](https://www.bitrise.io/integrations/steps/change-android-versioncode-and-versionname) Step. Set the input variables: 15 | - **Path to the build.gradle file**: The default value is `$PROJECT_LOCATION/$MODULE/build.gradle` and in most cases you don't have to change it. 16 | - **New versionName**: for example, `1.0.1`. 17 | - **New versionCode**: for example, `42`. 18 | 2. Add the [Android Build](https://bitrise.io/integrations/steps/android-build) step and set the following inputs: 19 | - **Build type**: Set this to `aab` 20 | - **Variant**: Use `release`, `debug`, or one of your custom variants if you have any. 21 | - **Module**: for example `$MODULE` . 22 | 3. Add the [Android Sign](https://bitrise.io/integrations/steps/sign-apk) Step. 23 | 4. Add the [Google Play Deploy](https://bitrise.io/integrations/steps/google-play-deploy) Step and set the following inputs: 24 | - **Service Account JSON key file path**: `$BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL`. 25 | - **Package name**: for example, `com.your.package.name`. 26 | - **Track**: Choose one of `internal`, `alpha`, `beta`, or `production`. 27 | - **Status**: The status of a release. For more information, see the [API reference](https://developers.google.com/android-publisher/api-ref/rest/v3/edits.tracks#Status). Recommended `draft` for production and `completed` for internal test builds. 28 | - Check the other options in the Workflow Editor or in the Step documentation. 29 | 30 | ## bitrise.yml 31 | 32 | ```yaml 33 | - change-android-versioncode-and-versionname@1: 34 | inputs: 35 | - new_version_name: 1.0.1 36 | - new_version_code: '42' 37 | - build_gradle_path: "$PROJECT_LOCATION/$MODULE/build.gradle" 38 | - android-build@1: 39 | inputs: 40 | - project_location: $PROJECT_LOCATION 41 | - module: $MODULE 42 | - build_type: aab 43 | - variant: release 44 | - sign-apk@1: {} 45 | - google-play-deploy@3: 46 | inputs: 47 | - service_account_json_key_path: $BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL 48 | - package_name: io.bitrise.sample.android 49 | - status: completed 50 | - track: internal 51 | ``` 52 | -------------------------------------------------------------------------------- /recipes/android-emulator-test.md: -------------------------------------------------------------------------------- 1 | # (Android) Run UI / instrumentation tests on local emulator 2 | 3 | ## Description 4 | 5 | Run UI / instrumentation tests on a local emulator instance. 6 | 7 | ## Instructions 8 | 9 | 1. Add an [AVD Manager](https://bitrise.io/integrations/steps/avd-manager) Step. To customize the emulator, see the [step configuration](https://github.com/bitrise-steplib/steps-avd-manager#%EF%B8%8F-configuration). 10 | 2. Add a [Wait for Android emulator](https://bitrise.io/integrations/steps/wait-for-android-emulator) step. 11 | 3. Add a [Gradle Runner](https://bitrise.io/integrations/steps/gradle-runner) step. Set the input variables: 12 | - **gradlew file path**: for example, `./gradlew`. 13 | - **Gradle task to run**: for example, `connectedDebugAndroidTest`. 14 | 4. Add a [Export test results to Test Reports add-on](https://bitrise.io/integrations/steps/custom-test-results-export) Step with the following inputs: 15 | - The name of the test: `Emulator tests`. 16 | - Test result base path: `$BITRISE_SOURCE_DIR/app/build/outputs/androidTest-results`. You might want to adjust the path based on the module name(s) in your project. 17 | - Test result search pattern: `*.xml`. 18 | 5. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). The failed tests will be also available under the `Test Results` tab on the build details page. 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - avd-manager@1: {} 24 | - wait-for-android-emulator@1: 25 | - gradle-runner@2: 26 | inputs: 27 | - gradlew_path: ./gradlew 28 | - gradle_task: connectedDebugAndroidTest 29 | - custom-test-results-export@1: 30 | inputs: 31 | - search_pattern: "*.xml" 32 | - base_path: $BITRISE_SOURCE_DIR/app/build/outputs/androidTest-results 33 | - test_name: Emulator tests 34 | - deploy-to-bitrise-io@2: 35 | ``` 36 | -------------------------------------------------------------------------------- /recipes/android-key-cache-build-tasks.md: -------------------------------------------------------------------------------- 1 | # (Android) Cache Gradle build tasks (Beta) 2 | 3 | ## Description 4 | 5 | Cache Gradle tasks with the new key-based caching Steps, **Save Gradle Cache** and **Restore Gradle Cache**. 6 | 7 | ## Prerequisites 8 | 9 | Make sure to read how to [cache Gradle dependencies](android-key-cache.md) and set up the Workflow according to the guide. Caching build tasks is an opt-in feature that builds on caching Gradle dependencies. 10 | 11 | ## Instructions 12 | 13 | [Gradle build cache](https://docs.gradle.org/current/userguide/build_cache.html) is a feature that enables the storage of the task outputs in the shared Gradle cache folder. Caching this folder in CI builds means that Gradle can reuse the task outputs from previous builds and can skip running the tasks when the inputs are unchanged. 14 | 15 | This is an opt-in feature. There are two ways to enable the build cache in a Gradle project: 16 | 17 | - add `org.gradle.caching = true` to the `gradle.properties` file in the project 18 | - pass the `--build-cache` CLI flag to each Gradle execution 19 | 20 | If you choose the second option and use Bitrise Android Steps, there is a Step input for additional Gradle arguments where you can define `--build-cache`. 21 | 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | - restore-gradle-cache@2: {} 27 | - android-build@1: 28 | inputs: 29 | - variant: debug 30 | - build_type: apk 31 | - arguments: --build-cache 32 | - save-gradle-cache@1: {} 33 | ``` 34 | -------------------------------------------------------------------------------- /recipes/android-key-cache.md: -------------------------------------------------------------------------------- 1 | # (Android) Cache Gradle dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache project dependencies that Gradle downloads with the new key-based caching Steps, **Save Gradle Cache** and **Restore Gradle Cache**. 6 | 7 | If you want to cache not only the dependencies but build tasks as well, check out [this workflow recipe](android-key-cache-build-tasks.md). 8 | 9 | ## Instructions 10 | 11 | 1. Add the [Restore Gradle Cache](https://bitrise.io/integrations/steps/restore-gradle-cache) Step to the Workflow. 12 | 1. Add the usual Android Steps, such as [Android Build](https://bitrise.io/integrations/steps/android-build). 13 | 1. Add the [Save Gradle Cache](https://bitrise.io/integrations/steps/save-gradle-cache) Step. 14 | 1. If you want to cache not only the dependencies but build tasks as well, check out [this workflow recipe](android-key-cache-build-tasks.md). 15 | 16 | ### Fine tune cache behaviour 17 | 18 | The Gradle specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://bitrise.io/integrations/steps/restore-cache) and [Save Cache](https://bitrise.io/integrations/steps/save-cache) Steps. 19 | 20 | You can always check out what key and path settings the Gradle cache step uses: 21 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-gradle-cache/blob/main/step/step.go#L14-L53) 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | - restore-gradle-cache@2: {} 27 | - android-build@1: 28 | inputs: 29 | - variant: debug 30 | - build_type: apk 31 | - save-gradle-cache@1: {} 32 | ``` 33 | -------------------------------------------------------------------------------- /recipes/android-lint.md: -------------------------------------------------------------------------------- 1 | # (Android) Run Lint 2 | 3 | ## Description 4 | Runs Lint on your Android project and generates a report with the results. 5 | 6 | ## Instructions 7 | 8 | 1. Add the [Android Lint](https://www.bitrise.io/integrations/steps/android-lint) step. Set the input variables: 9 | - **Project Location**: Use the default `$BITRISE_SOURCE_DIR` or `$PROJECT_LOCATION`. You can set a specific path but the automatically exposed Environment Variables are usually the best option. 10 | - **Variant**: Use the `$VARIANT` Enviromment Variable, or specify a variant manually. 11 | - **Module**: Specify one or leave it blank to run lint in all of the modules. 12 | 2. Add a [Deploy to Bitrise.io](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step. This Step uploads the lint report as a [build artifact](https://devcenter.bitrise.io/en/builds/managing-build-files/build-artifacts-online.html). 13 | 14 | ## bitrise.yml 15 | 16 | ```yaml 17 | - android-lint@0: 18 | inputs: 19 | - variant: $VARIANT 20 | - deploy-to-bitrise-io@2: {} 21 | ``` 22 | -------------------------------------------------------------------------------- /recipes/android-nightly-workflow.md: -------------------------------------------------------------------------------- 1 | # (Android) Example Nightly Workflow 2 | 3 | ## Description 4 | 5 | Example workflow for Android nightly builds. The workflow contains: 6 | 7 | 1. [Setting the version code and version name](https://www.bitrise.io/integrations/steps/change-android-versioncode-and-versionname). By default the app will get the build number (`$BITRISE_BUILD_NUMBER`) as the version code. 8 | 2. [Building a release Android App Bundle and uploading to Google Play internal testing](/recipes/android-deploy-to-google-play.md). 9 | 3. [Building a test app and uploading to bitrise.io](/recipes/android-deploy-to-bitrise.md). 10 | 4. [Sending the QR code of the test build to Slack](/recipes/slack-send-qr-code.md). 11 | 12 | Check out the [guide](https://devcenter.bitrise.io/en/builds/starting-builds/scheduling-builds.html) to run scheduled builds. 13 | 14 | ## Prerequisites 15 | 16 | 1. An Android keystore file is uploaded to Bitrise. For details, see [Android code signing using the Android Sign Step](https://devcenter.bitrise.io/en/code-signing/android-code-signing/android-code-signing-using-the-android-sign-step.html). 17 | 2. Google Play API Access is set up. For details, see [Deploying Android apps to Bitrise and Google Play](https://devcenter.bitrise.io/en/deploying/android-deployment/deploying-android-apps-to-bitrise-and-google-play.html#setting-up-google-play-api-access). 18 | 19 | ## bitrise.yml 20 | 21 | ```yaml 22 | --- 23 | format_version: '17' 24 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 25 | project_type: android 26 | 27 | meta: 28 | bitrise.io: 29 | stack: linux-docker-android-22.04 30 | machine_type_id: standard 31 | 32 | workflows: 33 | nightly: 34 | steps: 35 | - activate-ssh-key@4: 36 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 37 | - git-clone@8: {} 38 | - restore-gradle-cache@2: {} 39 | - change-android-versioncode-and-versionname@1: 40 | inputs: 41 | - new_version_name: 1.0.0 42 | - build_gradle_path: "$PROJECT_LOCATION/$MODULE/build.gradle" 43 | - android-build@1: 44 | inputs: 45 | - project_location: $PROJECT_LOCATION 46 | - module: $MODULE 47 | - build_type: aab 48 | - variant: release 49 | - sign-apk@1: {} 50 | - google-play-deploy@3: 51 | inputs: 52 | - service_account_json_key_path: $BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL 53 | - package_name: io.bitrise.sample.android 54 | - status: completed 55 | - track: internal 56 | - android-build@1: 57 | inputs: 58 | - project_location: $PROJECT_LOCATION 59 | - module: $MODULE 60 | - variant: $VARIANT 61 | - deploy-to-bitrise-io@2: {} 62 | - create-install-page-qr-code@1: {} 63 | - slack@4: 64 | inputs: 65 | - channel: "#build-notifications" 66 | - thumb_url: $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL 67 | - webhook_url: $SLACK_WEBHOOK 68 | - save-gradle-cache@1: {} 69 | 70 | app: 71 | envs: 72 | - opts: 73 | is_expand: false 74 | PROJECT_LOCATION: "." 75 | - opts: 76 | is_expand: false 77 | MODULE: app 78 | - VARIANT: debug 79 | opts: 80 | is_expand: false 81 | ``` 82 | 83 | ## Relevant Links 84 | 85 | * https://devcenter.bitrise.io/en/builds/starting-builds/scheduling-builds.html 86 | -------------------------------------------------------------------------------- /recipes/android-parallel-testing-unit-test-shards.md: -------------------------------------------------------------------------------- 1 | # (Android) Unit test sharding by module 2 | 3 | ## Description 4 | 5 | Running the unit tests of a modularized app in parallel Workflows utilizing Pipelines. 6 | 7 | This Pipeline contains two Workflows which are executed in parallel: 8 | 9 | 1. `unit_test_app`: This Workflow runs the unit tests of the `app` module using the `android-unit-test` Step. 10 | 1. `unit_test_library`: This Workflow runs the unit tests of the `lib-example` module using the `android-unit-test` Step. 11 | 12 | ![A screenshot of the example Pipeline in Bitrise's web UI](./android-parallel-testing-unit-test-shards.png) 13 | 14 | ## Instructions 15 | 16 | To test this configuration in a new Bitrise example project, do the following: 17 | 18 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 19 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git`) in the **Git repository (clone) URL** field. 20 | 1. Confirm that this is a public repository in the resulting pop-up. 21 | 1. Select the `main` branch to scan. 22 | 1. Wait for the project scanner to complete. 23 | 1. Enter `app` as the specified module. 24 | 1. Enter `debug` as the specified variant. 25 | 1. Continue through the prompts as normal — no changes are needed. 26 | 1. Open the new Bitrise project’s Workflow Editor. 27 | 1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `bitrise.yml` below. 28 | 1. Click the **Start/Schedule a Build** button, and select the `pipeline_unit_test` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 29 | 30 | ## bitrise.yml 31 | 32 | ```yaml 33 | format_version: "17" 34 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 35 | project_type: android 36 | 37 | meta: 38 | bitrise.io: 39 | stack: linux-docker-android-22.04 40 | machine_type_id: standard 41 | 42 | pipelines: 43 | pipeline_unit_test: 44 | workflows: 45 | unit_test_app: {} 46 | unit_test_library: {} 47 | 48 | workflows: 49 | unit_test_app: 50 | envs: 51 | - MODULE: app 52 | - VARIANT: debug 53 | after_run: 54 | - _test 55 | 56 | unit_test_library: 57 | envs: 58 | - MODULE: lib-example 59 | after_run: 60 | - _test 61 | 62 | _test: 63 | steps: 64 | - git-clone@8: {} 65 | - android-unit-test@1: 66 | inputs: 67 | - module: $MODULE 68 | - variant: $VARIANT 69 | ``` 70 | -------------------------------------------------------------------------------- /recipes/android-parallel-testing-unit-test-shards.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/android-parallel-testing-unit-test-shards.png -------------------------------------------------------------------------------- /recipes/android-parallel-ui-tests-on-multiple-devices.md: -------------------------------------------------------------------------------- 1 | # (Android) Run UI tests in parallel on multiple devices or shards 2 | 3 | ## Description 4 | 5 | Running the UI or instrumented tests of a single module in parallel Workflows utilizing Pipelines. You can run the tests in parallel by shards or by devices. 6 | 7 | The Pipeline's four Workflows can be split into two logical groups: 8 | 9 | 1. Build tests: First a single Workflow is executed — named `build_for_ui_testing` — that runs the `android-build-for-ui-testing` Step to build APKs for use in testing, and runs the `deploy-to-bitrise-io` Step to save those APKs for use in the later Workflows. Running this Workflow separately from the actual testing allows for each test Workflow to use these pre-built APKs rather than having to rebuild them for each test. 10 | 1. Run tests: Then three UI test Workflows are executed in parallel — `ui_test_on_phone`, `ui_test_on_tablet`, `ui_test_on_foldable` — which use the `android-instrumented-test` Step to run the UI tests on the APKs built in the previous Worflow on each specific device type. 11 | 12 | ![A screenshot of the example Pipeline in Bitrise's web UI](./android-parallel-ui-tests-on-multiple-devices.png) 13 | 14 | ## Instructions 15 | 16 | To test this configuration in a new Bitrise example project, do the following: 17 | 18 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 19 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git`) in the **Git repository (clone) URL** field. 20 | 1. Confirm that this is a public repository in the resulting pop-up. 21 | 1. Select the `main` branch to scan. 22 | 1. Wait for the project scanner to complete. 23 | 1. Enter `app` as the specified module. 24 | 1. Enter `debug` as the specified variant. 25 | 1. Continue through the prompts as normal — no changes are needed. 26 | 1. Open the new Bitrise project’s Workflow Editor. 27 | 1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `bitrise.yml` below. 28 | 1. Click the **Start/Schedule a Build** button, and select the `ui_test_on_multiple_devices` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 29 | 30 | ## bitrise.yml 31 | 32 | ```yaml 33 | format_version: "17" 34 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 35 | project_type: android 36 | 37 | meta: 38 | bitrise.io: 39 | stack: linux-docker-android-22.04 40 | machine_type_id: standard 41 | 42 | pipelines: 43 | ui_test_on_multiple_devices: 44 | workflows: 45 | build_for_ui_testing: {} 46 | ui_test_on_phone: 47 | depends_on: [build_for_ui_testing] 48 | ui_test_on_tablet: 49 | depends_on: [build_for_ui_testing] 50 | ui_test_on_foldable: 51 | depends_on: [build_for_ui_testing] 52 | 53 | workflows: 54 | build_for_ui_testing: 55 | steps: 56 | - git-clone@8: {} 57 | - android-build-for-ui-testing@0: 58 | inputs: 59 | - module: app 60 | - variant: debug 61 | - deploy-to-bitrise-io@2: 62 | inputs: 63 | - pipeline_intermediate_files: |- 64 | $BITRISE_APK_PATH:BITRISE_APK_PATH 65 | $BITRISE_TEST_APK_PATH:BITRISE_TEST_APK_PATH 66 | 67 | ui_test_on_phone: 68 | envs: 69 | - EMULATOR_PROFILE: pixel_5 70 | before_run: 71 | - _pull_apks 72 | after_run: 73 | - _run_tests 74 | 75 | ui_test_on_tablet: 76 | envs: 77 | - EMULATOR_PROFILE: 10.1in WXGA (Tablet) 78 | before_run: 79 | - _pull_apks 80 | after_run: 81 | - _run_tests 82 | 83 | ui_test_on_foldable: 84 | envs: 85 | - EMULATOR_PROFILE: 8in Foldable 86 | before_run: 87 | - _pull_apks 88 | after_run: 89 | - _run_tests 90 | 91 | _pull_apks: 92 | steps: 93 | - pull-intermediate-files@1: 94 | inputs: 95 | - artifact_sources: build_for_ui_testing 96 | 97 | _run_tests: 98 | steps: 99 | - avd-manager@1: 100 | inputs: 101 | - profile: $EMULATOR_PROFILE 102 | - wait-for-android-emulator@1: {} 103 | - android-instrumented-test@0: {} 104 | ``` 105 | -------------------------------------------------------------------------------- /recipes/android-parallel-ui-tests-on-multiple-devices.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/android-parallel-ui-tests-on-multiple-devices.png -------------------------------------------------------------------------------- /recipes/android-parallel-unit-and-ui-tests.md: -------------------------------------------------------------------------------- 1 | # (Android) Run unit and UI tests in parallel 2 | 3 | ## Description 4 | 5 | Running unit tests and UI tests in parallel utilizing Pipelines. 6 | 7 | This Pipeline contains two Workflows which are executed in parallel: 8 | 9 | 1. `unit_tests`: This Workflow simply runs the unit tests of the given module and variant using the `android-unit-test` Step. 10 | 1. `ui_tests`: This Workflow builds the given module and variant using the `android-build-for-ui-testing` Step, spins up an emulator using the `avd-manager` Step, waits for the emulator to boot using the `wait-for-android-emulator` Step, and runs the UI tests using the `android-instrumented-test` Step. 11 | 12 | ![A screenshot of the example Pipeline in Bitrise's web UI](./android-parallel-unit-and-ui-tests.png) 13 | 14 | ## Instructions 15 | 16 | To test this configuration in a new Bitrise example project, do the following: 17 | 18 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 19 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git`) in the **Git repository (clone) URL** field. 20 | 1. Confirm that this is a public repository in the resulting pop-up. 21 | 1. Select the `main` branch to scan. 22 | 1. Wait for the project scanner to complete. 23 | 1. Enter `app` as the specified module. 24 | 1. Enter `debug` as the specified variant. 25 | 1. Continue through the prompts as normal — no changes are needed. 26 | 1. Open the new Bitrise project’s Workflow Editor. 27 | 1. Go to the **bitrise.yml** tab, and replace the existing yaml contents with the contents of the example `bitrise.yml` below. 28 | 1. Click the **Start/Schedule a Build** button, and select the `pipeline_unit_and_ui_test` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 29 | 30 | ## bitrise.yml 31 | 32 | ```yaml 33 | format_version: "17" 34 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 35 | project_type: android 36 | 37 | meta: 38 | bitrise.io: 39 | stack: linux-docker-android-22.04 40 | machine_type_id: standard 41 | 42 | pipelines: 43 | pipeline_unit_and_ui_test: 44 | workflows: 45 | unit_tests: {} 46 | ui_tests: {} 47 | 48 | workflows: 49 | unit_tests: 50 | steps: 51 | - git-clone@8: {} 52 | - android-unit-test@1: 53 | inputs: 54 | - module: app 55 | - variant: debug 56 | 57 | ui_tests: 58 | steps: 59 | - git-clone@8: {} 60 | - android-build-for-ui-testing@0: 61 | inputs: 62 | - module: app 63 | - variant: debug 64 | - avd-manager@1: {} 65 | - wait-for-android-emulator@1: {} 66 | - android-instrumented-test@0: {} 67 | ``` 68 | -------------------------------------------------------------------------------- /recipes/android-parallel-unit-and-ui-tests.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/android-parallel-unit-and-ui-tests.png -------------------------------------------------------------------------------- /recipes/android-pull-request-workflow.md: -------------------------------------------------------------------------------- 1 | # (Android) Example Pull Request Workflow 2 | 3 | ## Description 4 | 5 | Example workflow for Android Pull Request validation. The workflow contains: 6 | 7 | 1. [Running unit tests](/recipes/android-unit-test.md) 8 | 2. [Running UI tests on a virtual device](/recipes/android-virtual-device-tests.md) 9 | 3. [Running lint](/recipes/android-lint.md) 10 | 4. [Building a test app and uploading to bitrise.io](/recipes/android-deploy-to-bitrise.md) 11 | 5. [Sending the QR code of the test build to the Pull Request](/recipes/github-pull-request-build-qr-code.md) 12 | 6. Triggering the Workflow for pull requests. 13 | 14 | ## Instructions 15 | 16 | Copy the yaml contents from below and make sure that the following env vars have the correct settings: 17 | - `$PROJECT_LOCATION` 18 | - `$MODULE` 19 | - `$VARIANT` 20 | 21 | Also generate a new Github access token and add a new secret called `GITHUB_ACCESS_TOKEN` with the newly generated token value. 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | --- 27 | format_version: '17' 28 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 29 | project_type: android 30 | 31 | meta: 32 | bitrise.io: 33 | stack: linux-docker-android-22.04 34 | machine_type_id: standard 35 | 36 | workflows: 37 | pull-request: 38 | steps: 39 | - activate-ssh-key@4: 40 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 41 | - git-clone@8: {} 42 | - restore-gradle-cache@2: {} 43 | - android-unit-test@1: 44 | inputs: 45 | - project_location: $PROJECT_LOCATION 46 | - variant: $VARIANT 47 | - android-build-for-ui-testing@0: 48 | inputs: 49 | - variant: $VARIANT 50 | - module: $MODULE 51 | - virtual-device-testing-for-android@1: 52 | inputs: 53 | - test_type: instrumentation 54 | - android-lint@0: 55 | inputs: 56 | - variant: $VARIANT 57 | - android-build@1: 58 | inputs: 59 | - project_location: $PROJECT_LOCATION 60 | - module: $MODULE 61 | - variant: $VARIANT 62 | - deploy-to-bitrise-io@2: {} 63 | - create-install-page-qr-code@1: {} 64 | - comment-on-github-pull-request@0: 65 | inputs: 66 | - body: |- 67 | ![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) 68 | 69 | $BITRISE_PUBLIC_INSTALL_PAGE_URL 70 | - personal_access_token: $GITHUB_ACCESS_TOKEN 71 | - save-gradle-cache@1: {} 72 | 73 | app: 74 | envs: 75 | - PROJECT_LOCATION: "." 76 | opts: 77 | is_expand: false 78 | - MODULE: app 79 | opts: 80 | is_expand: false 81 | - VARIANT: debug 82 | opts: 83 | is_expand: false 84 | 85 | trigger_map: 86 | - pull_request_source_branch: "*" 87 | workflow: pull-request 88 | ``` 89 | -------------------------------------------------------------------------------- /recipes/android-release-workflow.md: -------------------------------------------------------------------------------- 1 | # (Android) Example Release Workflow 2 | 3 | ## Description 4 | 5 | Example workflow for uploading a release draft of an app to Google Play. The workflow contains: 6 | 7 | 1. [Setting the verion name](https://www.bitrise.io/integrations/steps/change-android-versioncode-and-versionname) based on [Env Vars passed to the build](https://devcenter.bitrise.io/en/builds/environment-variables.html#setting-a-custom-env-var-when-starting-a-build) (`$VERSION_NAME`). 8 | 2. [Creating a release Android App Bundle and uploading it to Google Play](/recipes/android-deploy-to-google-play.md). 9 | 10 | ## Prerequisites 11 | 12 | 1. An Android keystore file is uploaded to Bitrise. For details, see [Android code signing using the Android Sign Step](https://devcenter.bitrise.io/en/code-signing/android-code-signing/android-code-signing-using-the-android-sign-step.html). 13 | 2. Google Play API Access is set up. For details, see [Deploying Android apps to Bitrise and Google Play](https://devcenter.bitrise.io/en/deploying/android-deployment/deploying-android-apps-to-bitrise-and-google-play.html#setting-up-google-play-api-access). 14 | 15 | ## Instructions 16 | 17 | Copy the yaml contents from below and make sure that the following env vars have the correct settings: 18 | - `$PROJECT_LOCATION` 19 | - `$MODULE` 20 | - `$VARIANT` 21 | 22 | This workflow will require setting the `$VERSION_NAME` env var for the build. Follow this [guide](https://devcenter.bitrise.io/en/builds/environment-variables.html#setting-a-custom-env-var-when-starting-a-build) on how to do it. 23 | 24 | ## bitrise.yml 25 | 26 | ```yaml 27 | --- 28 | format_version: '17' 29 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 30 | project_type: android 31 | 32 | meta: 33 | bitrise.io: 34 | stack: linux-docker-android-22.04 35 | machine_type_id: standard 36 | 37 | workflows: 38 | release: 39 | steps: 40 | - activate-ssh-key@4: 41 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 42 | - git-clone@8: {} 43 | - change-android-versioncode-and-versionname@1: 44 | inputs: 45 | - new_version_name: $VERSION_NAME 46 | - new_version_code: $BITRISE_BUILD_NUMBER 47 | - build_gradle_path: "$PROJECT_LOCATION/$MODULE/build.gradle" 48 | - android-build@1: 49 | inputs: 50 | - project_location: $PROJECT_LOCATION 51 | - module: $MODULE 52 | - build_type: aab 53 | - variant: release 54 | - sign-apk@1: {} 55 | - google-play-deploy@3: 56 | inputs: 57 | - service_account_json_key_path: "$BITRISEIO_SERVICE_ACCOUNT_JSON_KEY_URL" 58 | - package_name: io.bitrise.sample.android 59 | - status: draft 60 | - track: production 61 | 62 | app: 63 | envs: 64 | - PROJECT_LOCATION: "." 65 | opts: 66 | is_expand: false 67 | - MODULE: app 68 | opts: 69 | is_expand: false 70 | - VARIANT: debug 71 | opts: 72 | is_expand: false 73 | ``` 74 | 75 | ## Relevant Links 76 | 77 | * https://devcenter.bitrise.io/en/builds/environment-variables.html#setting-a-custom-env-var-when-starting-a-build 78 | -------------------------------------------------------------------------------- /recipes/android-unit-test.md: -------------------------------------------------------------------------------- 1 | # (Android) Run unit tests 2 | 3 | ## Description 4 | 5 | Run unit tests (for example, `testDebugUnitTest`). 6 | 7 | ## Instructions 8 | 9 | 1. Add an [Android Unit Test](https://www.bitrise.io/integrations/steps/android-unit-test) Step. Input variables you might set: 10 | - **Project Location**: Use the default `$BITRISE_SOURCE_DIR` or `$PROJECT_LOCATION`. You can set a specific path but the automatically exposed Environment Variables are usually the best option. 11 | - **Variant**: Use the `$VARIANT` Enviromment Variable, or specify a variant manually. 12 | - **Module**: Specify one or leave it blank to run tests in all of the modules. 13 | 2. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). The failed tests will be also available under the `Test Results` tab on the build details page. 14 | 15 | ## bitrise.yml 16 | 17 | ```yaml 18 | - android-unit-test@1: 19 | inputs: 20 | - project_location: $PROJECT_LOCATION 21 | - variant: $VARIANT 22 | - deploy-to-bitrise-io@2: {} 23 | ``` 24 | 25 | ## Related Links 26 | 27 | * https://devcenter.bitrise.io/en/testing/android-unit-tests.html 28 | -------------------------------------------------------------------------------- /recipes/android-virtual-device-tests.md: -------------------------------------------------------------------------------- 1 | # (Android) Run UI / instrumentation tests on virtual devices 2 | 3 | ## Description 4 | 5 | Run UI / instrumentation (for example, Espresso) or robo/gameloop tests on virtual devices. [Our device testing solution](https://devcenter.bitrise.io/en/testing/device-testing-for-android.html) is based on Firebase Test Lab. You can find the resulting logs, videos and screenshots on Bitrise. 6 | 7 | ## Instructions 8 | 9 | 1. Add an [Android Build for UI Testing](https://bitrise.io/integrations/steps/android-build-for-ui-testing) Step. Set the input variables: 10 | - **Project Location**: Use the default `$BITRISE_SOURCE_DIR` or `$PROJECT_LOCATION`. You can set a specific path but the automatically exposed Environment Variables are usually the best option. 11 | - **Variant**: Use the `$VARIANT` Enviromment Variable, or specify a variant manually. 12 | - **Module**: Specify one or leave it blank to run tests in all of the modules. 13 | 2. Add a [[BETA] Virtual Device Testing for Android](https://www.bitrise.io/integrations/steps/virtual-device-testing-for-android) Step. Set the input variables: 14 | - **Test type**: `instrumentation` (or `robo` or `gameloop`) 15 | - (Optional) **Test devices** (default: `NexusLowRes,24,en,portrait`) 16 | 3. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). 17 | 18 | ## bitrise.yml 19 | 20 | ```yaml 21 | - android-build-for-ui-testing@0: 22 | inputs: 23 | - variant: $VARIANT 24 | - module: $MODULE 25 | - virtual-device-testing-for-android@1: 26 | inputs: 27 | - test_type: instrumentation 28 | - deploy-to-bitrise-io@2: {} 29 | ``` 30 | 31 | ## Links 32 | 33 | * https://devcenter.bitrise.io/en/testing/device-testing-for-android.html 34 | -------------------------------------------------------------------------------- /recipes/flutter-dart-analyzer.md: -------------------------------------------------------------------------------- 1 | # (Flutter) Run Dart Analyzer 2 | 3 | ## Description 4 | Runs the Dart Analyzer. 5 | 6 | ## Instructions 7 | 8 | 1. Add the [Flutter Analyze](https://www.bitrise.io/integrations/steps/flutter-analyze) Step to your Workflow. 9 | 10 | ## bitrise.yml 11 | 12 | ```yaml 13 | - flutter-analyze@0: 14 | inputs: 15 | - project_location: $BITRISE_FLUTTER_PROJECT_LOCATION 16 | ``` 17 | -------------------------------------------------------------------------------- /recipes/flutter-install-flutter-sdk.md: -------------------------------------------------------------------------------- 1 | # (Flutter) Install Flutter SDK 2 | 3 | ## Description 4 | 5 | Install the latest stable/beta or a specific version of Flutter. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Flutter Install](https://www.bitrise.io/integrations/steps/flutter-installer) step. **Use this step before the Cache Pull step to make sure caching works correctly.** 10 | 2. You can install either the latest stable/beta versions or a specific version: 11 | - By default, the Step installs the latest stable version. 12 | - To install the latest beta, set the **Flutter SDK git repository version** input to `beta`. 13 | - **Recommended:** To install a specific version, set the **Flutter SDK installation bundle URL** input. You can find the list of Flutter installation bundles here: https://flutter.dev/docs/development/tools/sdk/releases. Make sure you set the bundle based on the stack (MacOS or Linux). 14 | 15 | ## bitrise.yml 16 | 17 | Specific version (recommended): 18 | 19 | ```yaml 20 | - flutter-installer@0: 21 | inputs: 22 | - installation_bundle_url: https://storage.googleapis.com/flutter_infra_release/releases/stable/macos/flutter_macos_2.5.3-stable.zip 23 | ``` 24 | 25 | Latest stable: 26 | 27 | ```yaml 28 | - flutter-installer@0: {} 29 | ``` 30 | 31 | Latest beta: 32 | 33 | ```yaml 34 | - flutter-installer@0: 35 | inputs: 36 | - version: beta 37 | ``` 38 | -------------------------------------------------------------------------------- /recipes/flutter-key-cache.md: -------------------------------------------------------------------------------- 1 | # (Flutter) Cache Dart dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache the contents of the [Dart pub system cache](https://dart.dev/tools/pub/glossary#system-cache) folder with the new key-based caching Steps, **Save Dart Cache** and **Restore Dart Cache**. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Restore Dart Cache](https://bitrise.io/integrations/steps/restore-dart-cache) Step to the Workflow. 10 | 1. Add one of Flutter Steps to the workflow, such as [Flutter Build](https://www.bitrise.io/integrations/steps/flutter-build) 11 | 1. Add the [Save Dart Cache](https://bitrise.io/integrations/steps/save-dart-cache) Step. 12 | 13 | ### Fine tune cache behaviour 14 | 15 | The Dart specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://bitrise.io/integrations/steps/restore-cache) and [Save Cache](https://bitrise.io/integrations/steps/save-cache) Steps. 16 | 17 | You can always check out what key and path settings the Dart cache step uses: 18 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-dart-cache/blob/main/step/step.go#L13-L22) 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - restore-dart-cache@2: {} 24 | - flutter-build@0: {} 25 | - save-dart-cache@1: {} 26 | ``` 27 | -------------------------------------------------------------------------------- /recipes/flutter-test.md: -------------------------------------------------------------------------------- 1 | # (Flutter) Run tests 2 | 3 | ## Description 4 | Performs any test in a Flutter project. 5 | 6 | ## Instructions 7 | 8 | 1. Add the [Flutter Test](https://bitrise.io/integrations/steps/flutter-test) Step to your Workflow. Set the input variables: 9 | - **Project Location**: For example, `$BITRISE_FLUTTER_PROJECT_LOCATION`. 10 | - Check out optional inputs in the Workflow Editor or in the Step description. 11 | 2. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). The failed tests will be also available under the `Test Results` tab on the build details page. 12 | 13 | ## bitrise.yml 14 | 15 | ```yaml 16 | - flutter-test@1: 17 | inputs: 18 | - project_location: $BITRISE_FLUTTER_PROJECT_LOCATION 19 | - deploy-to-bitrise-io@2: {} 20 | ``` 21 | -------------------------------------------------------------------------------- /recipes/github-pull-request-build-qr-code.md: -------------------------------------------------------------------------------- 1 | # GitHub pull request - send the build QR code 2 | 3 | ## Description 4 | Send a comment to the GitHub pull request with a QR code to the build uploaded to Bitrise.io. 5 | 6 | ## Prerequisites 7 | 8 | 1. You have your iOS or Android app archived. 9 | 2. Generate a [GitHub personal access token](https://github.com/settings/tokens) and add it as a Secret (`$GITHUB_ACCESS_TOKEN`). Make sure to select the `repo` scope. 10 | 11 | ## Instructions 12 | 13 | 1. Add the [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step. 14 | 2. Add the [Create install page QR code](https://www.bitrise.io/integrations/steps/create-install-page-qr-code) Step. 15 | 3. Add the [Comment on GitHub Pull Request](https://www.bitrise.io/integrations/steps/comment-on-github-pull-request) Step. Set the following input variables: 16 | - **GitHub personal access token**: Set it to the previously created Secret, `$GITHUB_ACCESS_TOKEN`. 17 | - **Body**: 18 | 19 | ``` 20 | ![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) 21 | 22 | $BITRISE_PUBLIC_INSTALL_PAGE_URL 23 | ``` 24 | 25 | ## bitrise.yml 26 | 27 | ```yaml 28 | - deploy-to-bitrise-io@2: {} 29 | - create-install-page-qr-code@1: {} 30 | - comment-on-github-pull-request@0: 31 | inputs: 32 | - body: |- 33 | ![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) 34 | 35 | $BITRISE_PUBLIC_INSTALL_PAGE_URL 36 | - personal_access_token: $GITHUB_ACCESS_TOKEN 37 | ``` 38 | -------------------------------------------------------------------------------- /recipes/gradle-build-profiling.md: -------------------------------------------------------------------------------- 1 | # Turn on Gradle build profiling 2 | 3 | ## Description 4 | Generate and store a performance report of every Gradle build to spot build speed issues or compare different builds. 5 | 6 | ## Instructions 7 | 8 | No matter what Android or Gradle Step you use in your Bitrise Workflow, there is an option to define additional command line arguments for Gradle. Add `--profile` to this input to generate a performance report of the Gradle tasks. In the example below, we are adding the argument to the Android Unit Test Step. 9 | 10 | To sum up the procedure: 11 | 1. Add the Android Unit Test Step to your Workflow. 12 | 2. Add a Script Step to compress the reports and copy the ZIP file to the deploy directory. 13 | 3. Trigger a manual build and download and open the HTML report. 14 | 4. Check the various aspects of the build in the report. 15 | 16 | ### Adding the Android Unit Test Step 17 | 18 | Add an Android Unit Test Step to your Workflow. Set the necessary input values: 19 | 20 | - **Project location**: "$PROJECT_LOCATION" 21 | - **Module**: "$MODULE" 22 | - **Variant**: "$VARIANT" 23 | - **Arguments**: "--profile" 24 | 25 | ### Compressing the report files and copying the ZIP file 26 | 27 | Add a Script Step to the end of the Workflow in order to compress the report files and copy the ZIP file to the deploy directory: 28 | 29 | ``` 30 | #!/usr/bin/env bash 31 | # fail if any commands fails 32 | set -e 33 | # debug log 34 | set -x 35 | 36 | zip -r $BITRISE_DEPLOY_DIR/gradle-profile.zip $PROJECT_LOCATION/build/reports/profile 37 | ``` 38 | Gradle creates the HTML report in build/reports/profile/, so we need to take all files in that folder (HTML, CSS and JS files), compress them, and move the ZIP archive to $BITRISE_DEPLOY_DIR. Files in this folder can be accessed on the build page’s Apps & Artifacts tab. 39 | 40 | ### Downloading the report file 41 | 42 | Trigger a manual build of the Workflow you edited previously. Download and unarchive `gradle-profile.zip`, then open the HTML report in your browser. 43 | 44 | ![image](https://user-images.githubusercontent.com/5689177/149338897-3ab06e6a-9b58-465f-95fc-45235afff259.png) 45 | 46 | ![image](https://user-images.githubusercontent.com/5689177/149339159-0ad35634-518e-464c-a460-2c7c636cae4a.png) 47 | 48 | 49 | 50 | ### Checking the build report 51 | 52 | You can check various aspects of a build in the report: 53 | 54 | - The **Summary** tab shows time spent on things other than task execution 55 | 56 | - The **Task execution** tab lists all tasks sorted by execution time 57 | 58 | - Cached tasks are marked as **UP-TO-DATE**. This helps to fine-tune the [Bitrise Cache Steps](https://devcenter.bitrise.io/builds/caching/about-caching-index/) by comparing the reports of multiple builds. 59 | 60 | For Gradle optimization ideas, check out [this article by Google](https://developer.android.com/studio/build/profile-your-build#using-the-gradle---profile-option). 61 | 62 | If you only want to display task execution times only in the build log, you can use the [build-time-tracker](https://github.com/asarkar/build-time-tracker) project. 63 | 64 | ## bitrise.yml 65 | 66 | ```yaml 67 | - android-unit-test@1: 68 | inputs: 69 | - project_location: $PROJECT_LOCATION 70 | - module: $MODULE 71 | - arguments: "--profile" 72 | - variant: $VARIANT 73 | - script@1: 74 | title: Collect Gradle profile report 75 | inputs: 76 | - content: |- 77 | #!/usr/bin/env bash 78 | # fail if any commands fails 79 | set -e 80 | # debug log 81 | set -x 82 | 83 | zip -r $BITRISE_DEPLOY_DIR/gradle-profile.zip $PROJECT_LOCATION/build/reports/profile 84 | - deploy-to-bitrise-io@2: {} 85 | ``` 86 | -------------------------------------------------------------------------------- /recipes/ios-ci-workflow.md: -------------------------------------------------------------------------------- 1 | # (iOS) Example CI Workflow 2 | 3 | ## Description 4 | 5 | Example Workflow for commits on the main branch of an iOS app. The Workflow contains: 6 | 7 | 1. Installing [Cocoapods](/recipes/ios-key-cache-cocoapods.md) and [Carthage](/recipes/ios-install-carthage-dependencies.md) dependecies. 8 | 2. [Running all unit and UI tests in simulator](/recipes/ios-simulator-test.md) 9 | 3. [Building a test app and uploading to bitrise.io](/recipes/ios-deploy-to-bitrise.md) 10 | 4. [Sending a Slack notification with the build status](/recipes/slack-send-build-status.md) 11 | 12 | ## bitrise.yml 13 | 14 | ```yaml 15 | --- 16 | format_version: '17' 17 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 18 | project_type: ios 19 | 20 | meta: 21 | bitrise.io: 22 | stack: osx-xcode-16.0.x 23 | machine_type_id: g2.mac.medium 24 | 25 | workflows: 26 | ci: 27 | steps: 28 | - activate-ssh-key@4: 29 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 30 | - git-clone@8: {} 31 | - restore-cocoapods-cache@2: {} 32 | - cocoapods-install@2: {} 33 | - restore-carthage-cache@2: {} 34 | - carthage@3: 35 | inputs: 36 | - carthage_options: "--use-xcframeworks --platform iOS" 37 | - restore-spm-cache@2: {} 38 | - xcode-test@5: 39 | inputs: 40 | - log_formatter: xcodebuild 41 | - xcodebuild_options: "-enableCodeCoverage YES" 42 | - xcode-archive@5: 43 | inputs: 44 | - project_path: $BITRISE_PROJECT_PATH 45 | - scheme: $BITRISE_SCHEME 46 | - automatic_code_signing: apple-id 47 | - distribution_method: development 48 | - save-spm-cache@1: {} 49 | - save-carthage-cache@1: {} 50 | - save-cocoapods-cache@1: {} 51 | - deploy-to-bitrise-io@2: {} 52 | - slack@4: 53 | inputs: 54 | - channel: "#build-notifications" 55 | - webhook_url: $SLACK_WEBHOOK 56 | 57 | app: 58 | envs: 59 | - BITRISE_PROJECT_PATH: BitriseTest.xcworkspace 60 | opts: 61 | is_expand: false 62 | - BITRISE_SCHEME: BitriseTest 63 | opts: 64 | is_expand: false 65 | - BITRISE_DISTRIBUTION_METHOD: development 66 | opts: 67 | is_expand: false 68 | 69 | trigger_map: 70 | - push_branch: main 71 | workflow: ci 72 | ``` 73 | -------------------------------------------------------------------------------- /recipes/ios-deploy-to-appcenter.md: -------------------------------------------------------------------------------- 1 | # (iOS) Deploy to Visual Studio App Center 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via AppCenter. 6 | 7 | ## Prerequisites 8 | 9 | 1. An existing [Visual Studio App Center](https://docs.microsoft.com/en-us/appcenter/dashboard/) project where your app is registered. 10 | 2. Adding the API token as a [Secret](https://devcenter.bitrise.io/en/builds/secrets.html) your Bitrise project with the name `APPCENTER_API_TOKEN`. 11 | 3. You have code signing set up. See [iOS Code Signing](https://devcenter.bitrise.io/en/code-signing/ios-code-signing.html) for more details. 12 | 13 | ## Instructions 14 | 15 | 1. Add the [Xcode Archive & Export for iOS](https://bitrise.io/integrations/steps/xcode-archive) step. Set the input variables: 16 | - **Project path**: by default `$BITRISE_PROJECT_PATH`. 17 | - **Scheme**: by default `$BITRISE_SCHEME`. 18 | - **Distribution method**: `development`, `ad-hoc` or `enterprise`. 19 | 3. Add the [AppCenter iOS Deploy](https://www.bitrise.io/integrations/steps/appcenter-deploy-ios) step and set the following inputs: 20 | - **API Token**: `$APPCENTER_API_TOKEN`. 21 | - **Owner name**: for example, `my-company`. 22 | - **App name**: for example, `my-app` Use the [App Center CLI](https://github.com/Microsoft/appcenter-cli) to get the app name since it might not be the same as the one you can see on the Visual Studio App Center website. 23 | - Check out other options in the Step documentation or in the Workflow Editor. 24 | 25 | ## bitrise.yml 26 | 27 | ```yaml 28 | - xcode-archive@5: 29 | inputs: 30 | - project_path: $BITRISE_PROJECT_PATH 31 | - scheme: $BITRISE_SCHEME 32 | - automatic_code_signing: apple-id 33 | - distribution_method: development 34 | - appcenter-deploy-ios@2: 35 | inputs: 36 | - owner_name: my-company 37 | - app_name: my-app 38 | - api_token: $APPCENTER_API_TOKEN 39 | ``` 40 | -------------------------------------------------------------------------------- /recipes/ios-deploy-to-appstore.md: -------------------------------------------------------------------------------- 1 | # (iOS) Deploy to App Store Connect / TestFlight 2 | 3 | ## Description 4 | Archiving the app and uploading to App Store Connect to either release it to App Store or to TestFlight. 5 | 6 | ## Prerequisites 7 | 8 | 1. The source code is cloned and the dependencies (for example, Cocoapods, Carthage) are installed. 9 | 2. You have code signing set up. See [iOS Code Signing](https://devcenter.bitrise.io/en/code-signing/ios-code-signing.html) for more details. 10 | 3. You have Apple Developer connection set up. See [Apple services connection](https://devcenter.bitrise.io/en/accounts/connecting-to-services/apple-services-connection.html) for more details. 11 | 12 | ## Instructions 13 | 14 | 1. (Optional) Add the [Set Xcode Project Build Number](https://www.bitrise.io/integrations/steps/set-xcode-build-number) Step. Set the input variables: 15 | - **Info.plist file path**: for example, `MyApp/Info.plist`. 16 | - **Build Number**: for example, `42`. 17 | - **Version Number**: for example, `1.1`. 18 | 2. Add the [Xcode Archive & Export for iOS](https://bitrise.io/integrations/steps/xcode-archive) step. Set the input variables: 19 | - **Project path**: by default `$BITRISE_PROJECT_PATH`. Normally, you don't have to change this. 20 | - **Scheme**: by default `$BITRISE_SCHEME`. This Environment Variable stores the scheme that you set when adding the app. The scheme always must be a shared scheme. 21 | - **Distribution method**: it must be set to `app-store`. 22 | 3. Add the [Deploy to App Store Connect - Application Loader (formerly iTunes Connect)](https://bitrise.io/integrations/steps/deploy-to-itunesconnect-application-loader) Step. Set the input variables: 23 | - **Bitrise Apple Developer Connection**: for example, `api_key` 24 | 25 | Alternatively you can use the [Deploy to App Store Connect with Deliver (formerly iTunes Connect)](https://bitrise.io/integrations/steps/deploy-to-itunesconnect-deliver) step as well, which gives you more options. 26 | 27 | ## bitrise.yml 28 | 29 | ```yaml 30 | - set-xcode-build-number@2: 31 | inputs: 32 | - build_short_version_string: '1.0' 33 | - xcode-archive@5: 34 | inputs: 35 | - project_path: $BITRISE_PROJECT_PATH 36 | - scheme: $BITRISE_SCHEME 37 | - automatic_code_signing: api_key 38 | - distribution_method: app-store 39 | - deploy-to-itunesconnect-application-loader@1: 40 | inputs: 41 | - connection: api_key 42 | ``` 43 | -------------------------------------------------------------------------------- /recipes/ios-deploy-to-bitrise.md: -------------------------------------------------------------------------------- 1 | # (iOS) Deploy to bitrise.io 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via [Bitrise.io Ship](https://devcenter.bitrise.io/en/deploying/deploying-with-ship.html). 6 | 7 | ## Prerequisites 8 | 9 | 1. You have code signing set up. See [iOS Code Signing](https://devcenter.bitrise.io/en/code-signing/ios-code-signing.html) for more details. 10 | 11 | ## Instructions 12 | 13 | 1. Add the [Xcode Archive & Export for iOS](https://bitrise.io/integrations/steps/xcode-archive) step. Set the input variables: 14 | - **Project path**: by default, `$BITRISE_PROJECT_PATH`. 15 | - **Scheme**: by default, `$BITRISE_SCHEME`. 16 | - **Distribution method**: `development`, `ad-hoc` or `enterprise`. 17 | 2. Add the [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step. 18 | 19 | ## bitrise.yml 20 | 21 | ```yaml 22 | - xcode-archive@5: 23 | inputs: 24 | - project_path: $BITRISE_PROJECT_PATH 25 | - scheme: $BITRISE_SCHEME 26 | - automatic_code_signing: apple-id 27 | - distribution_method: development 28 | - deploy-to-bitrise-io@2: {} 29 | ``` 30 | -------------------------------------------------------------------------------- /recipes/ios-deploy-to-firebase.md: -------------------------------------------------------------------------------- 1 | # (iOS) Deploy to Firebase App Distribution 2 | 3 | ## Description 4 | 5 | Build and distribute your app to testers via Firebase App Distribution. 6 | 7 | ## Prerequisites 8 | 9 | * An existing Firebase project where your exact bundle ID is registered. Follow the [Firebase documentation](https://firebase.google.com/docs/app-distribution/ios/distribute-console) for details. 10 | * Obtain a token from Firebase by running `firebase login:ci` locally. See the [Firebase CLI](https://firebase.google.com/docs/cli#sign-in-test-cli) docs for more details. 11 | * Add this token as a secret your Bitrise project with the name `FIREBASE_TOKEN`. 12 | * Get your Firebase App ID from your project's **General Settings** page and pass this value as an input to the `firebase-app-distribution` Step. 13 | * Settings up code signing on Bitrise is not part of this guide, please follow our [code signing docs](https://devcenter.bitrise.io/en/code-signing/ios-code-signing.html#ios-code-signing-53933) for instructions. 14 | 15 | ## Instructions 16 | 17 | 1. Add the [Xcode Archive](https://bitrise.io/integrations/steps/xcode-archive) Step and set the required inputs, such as scheme, distribution method and the desired code signing method. 18 | 2. Add the [Firebase App Distribution](https://bitrise.io/integrations/steps/firebase-app-distribution) Step and set the following inputs: 19 | * **Firebase token**: use the secret env var previously defined: `$FIREBASE_TOKEN`. 20 | * **Firebase App ID**: see the Prerequisites section above for details. 21 | * Optionally, you can define test groups or individual testers in the Step inputs. 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | - xcode-archive@5: 27 | inputs: 28 | - distribution_method: development 29 | - scheme: $BITRISE_SCHEME 30 | - automatic_code_signing: api-key 31 | - firebase-app-distribution@0: 32 | inputs: 33 | - firebase_token: $FIREBASE_TOKEN 34 | - app: 1:1234567890:ios:321abc456def7890 # your app ID from Firebase 35 | - testers: email@company.com # optional 36 | - groups: qa-team #optional 37 | ``` 38 | -------------------------------------------------------------------------------- /recipes/ios-device-testing.md: -------------------------------------------------------------------------------- 1 | # (iOS) Run Tests on a Physical Device 2 | 3 | ## Description 4 | 5 | Run unit or UI tests on a physical device. Our device testing solution is based on Firebase Test Lab. You can find the resulting logs, videos and screenshots on Bitrise. 6 | 7 | ## Prerequisites 8 | 9 | 1. The source code is cloned and the dependencies (for example, Cocoapods, Carthage) are installed. 10 | 2. You have code signing set up. See [iOS Code Signing](https://devcenter.bitrise.io/en/code-signing/ios-code-signing.html) for more details. 11 | 12 | ## Instructions 13 | 14 | 1. Add an [Xcode Build for testing for iOS](https://bitrise.io/integrations/steps/xcode-build-for-test) Step. 15 | 2. Add a [[BETA] iOS Device Testing](https://www.bitrise.io/integrations/steps/virtual-device-testing-for-ios) Step. 16 | - Setup code signing for the Step. 17 | 3. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). 18 | 19 | ## bitrise.yml 20 | 21 | ```yaml 22 | - xcode-build-for-test@3: 23 | inputs: 24 | - automatic_code_signing: api_key 25 | - virtual-device-testing-for-ios@1: {} 26 | - deploy-to-bitrise-io@2: {} 27 | ``` 28 | 29 | ## Relevant Links 30 | 31 | * https://devcenter.bitrise.io/en/testing/device-testing-for-ios.html 32 | -------------------------------------------------------------------------------- /recipes/ios-install-carthage-dependencies.md: -------------------------------------------------------------------------------- 1 | # (iOS) Install Carthage Dependencies 2 | 3 | ## Description 4 | 5 | Installing Carthage dependecies. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Carthage](https://bitrise.io/integrations/steps/carthage) Step. Set the input variables: 10 | - **Github Personal Access Token**: We recommend adding a GitHub access token to your Secrets (`$GITHUB_ACCESS_TOKEN`). We need this token to avoid GitHub rate limit issue. See the GitHub guide: [Creating an access token for command-line use](https://help.github.com/articles/creating-an-access-token-for-command-line-use/) on how to create Personal Access Token. Uncheck every scope box when creating this token. There is no reason this token needs access to private information. 11 | - (Optional) **Additional options for carthage command**: See the [Carthage docs](https://github.com/Carthage/Carthage) for the available options, for example, `--use-xcframeworks --platform iOS`. 12 | 13 | ## bitrise.yml 14 | 15 | ``` 16 | - carthage@3: 17 | inputs: 18 | - carthage_options: "--use-xcframeworks --platform iOS" 19 | ``` 20 | -------------------------------------------------------------------------------- /recipes/ios-install-cocoapods-dependencies.md: -------------------------------------------------------------------------------- 1 | # (iOS) Install CocoaPods Dependencies 2 | 3 | ## Description 4 | 5 | Installing CocoaPods dependecies. **Make sure that you are using the workspace and not the project file in your steps. Check the value of `$BITRISE_PROJECT_PATH` env var.** 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Run CocoaPods install](https://bitrise.io/integrations/steps/cocoapods-install) Step. 10 | 2. (Optional) If your Podfile is not in the root, you can set the **Podfile path** input. 11 | 12 | ## bitrise.yml 13 | 14 | ```yaml 15 | - cocoapods-install@2: {} 16 | ``` 17 | -------------------------------------------------------------------------------- /recipes/ios-key-cache-carthage.md: -------------------------------------------------------------------------------- 1 | # (iOS) Cache Carthage dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache the contents of the `Carthage` folder with the new key-based caching Steps, **Save Cache** and **Restore Cache**. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Restore Carthage Cache](https://bitrise.io/integrations/steps/restore-carthage-cache) Step to the Workflow. 10 | 1. Add the [Carthage](https://bitrise.io/integrations/steps/carthage) Step. 11 | 1. Add the [Save Carthage Cache](https://bitrise.io/integrations/steps/save-carthage-cache) Step. 12 | 13 | ### Fine tune cache behaviour 14 | 15 | The Carthage specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://bitrise.io/integrations/steps/restore-cache) and [Save Cache](https://bitrise.io/integrations/steps/save-cache) Steps. 16 | 17 | You can always check out what key and path settings the Carthage cache step uses: 18 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-carthage-cache/blob/main/step/step.go#L14-L34) 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - restore-carthage-cache@2: {} 24 | - carthage@3: {} 25 | - save-carthage-cache@1: {} 26 | ``` 27 | -------------------------------------------------------------------------------- /recipes/ios-key-cache-cocoapods.md: -------------------------------------------------------------------------------- 1 | # (iOS) Cache CocoaPods dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache the contents of the `Pods` folder with the new key-based caching Steps, **Save Cache** and **Restore Cache**. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Restore Cocoapods Cache](https://bitrise.io/integrations/steps/restore-cocoapods-cache) Step to the Workflow. 10 | 1. Add the [Run CocoaPods install](https://bitrise.io/integrations/steps/cocoapods-install) Step. 11 | 1. Add the [Save Cocoapods Cache](https://bitrise.io/integrations/steps/save-cocoapods-cache) Step. 12 | 13 | ### Fine tune cache behaviour 14 | 15 | The Cocoapods specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://bitrise.io/integrations/steps/restore-cache) and [Save Cache](https://bitrise.io/integrations/steps/save-cache) Steps. 16 | 17 | You can always check out what key and path settings the Cocapods cache step uses: 18 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-cocoapods-cache/blob/main/step/step.go#L13-L23) 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - restorecocopods-cache@2: {} 24 | - cocoapods-install@2: {} 25 | - save-cocopods-cache@1: {} 26 | ``` 27 | -------------------------------------------------------------------------------- /recipes/ios-key-cache-spm.md: -------------------------------------------------------------------------------- 1 | # (iOS) Cache Swift Package Manager dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache the resolved Swift package dependencies with the new key-based caching Steps, **Save Cache** and **Restore Cache**. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Restore SPM Cache](https://bitrise.io/integrations/steps/restore-spm-cache) Step to the Workflow. 10 | 1. Add one of the usual iOS build steps, such as [Xcode Test for iOS](https://www.bitrise.io/integrations/steps/xcode-test). 11 | 1. Add the [Save SPM Cache](https://bitrise.io/integrations/steps/save-spm-cache) Step. 12 | 13 | ### Fine tune cache behaviour 14 | 15 | The SPM specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://bitrise.io/integrations/steps/restore-cache) and [Save Cache](https://bitrise.io/integrations/steps/save-cache) Steps. 16 | 17 | You can always check out what key and path settings the SPM cache step uses: 18 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-spm-cache/blob/main/step/step.go#L13-L26) 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - restore-spm-cache@2: {} 24 | - xcode-test@5: {} 25 | - save-spm-cache@1: {} 26 | ``` 27 | -------------------------------------------------------------------------------- /recipes/ios-merging-test-results-and-deploying-to-the-test-reports-add-on.md: -------------------------------------------------------------------------------- 1 | # (iOS) Merging test results and deploying to the Test Reports add-on 2 | 3 | ## Description 4 | 5 | Test Reports add-on is tied to Bitrise builds. To make all the test reports generated in different builds appear on a single page in the add-on, the reports need to be merged and deployed in an additional build. 6 | 7 | This example uses the [sample-swift-project-with-parallel-ui-test](https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) iOS Open Source sample app and extends the ‘Run iOS test groups in parallel’ example Pipeline config with merging and deploying test results. 8 | 9 | `run_ui_tests` and `run_unit_tests` Workflows are extended with a `deploy-to-bitrise-io` Step to make the generated test results available for the following workflows in the graph. 10 | 11 | `build_and_run_tests` Pipeline is extended with a new workflow: `deploy_test_results`. 12 | 13 | This Workflow does the following: 14 | 1. `pull-intermediate-files` Step downloads test results generated in the previous workflow (`run_tests`). 15 | 1. `script` Step moves each test result into a new test run directory within the Test Report add-on deploy dir and creates the related `test-info.json` file. 16 | 1. `deploy-to-bitrise-io` Step deploys the merged test results. 17 | 18 | ![A screenshot of the example Pipeline in Bitrise's web UI](./ios-merging-test-results-and-deploying-to-the-test-reports-add-on.png) 19 | 20 | ## Instructions 21 | 22 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 23 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test`) in the **Git repository (clone) URL** field. 24 | 1. Confirm that this is a public repository in the resulting pop-up. 25 | 1. Select the `master` branch to scan. 26 | 1. Wait for the project scanner to complete. 27 | 1. Select any of the offered Distribution methods (for example development, it does not really matter as now we are focusing on testing). 28 | 1. Confirm the offered stack, skip choosing the app icon and the webhook registration and kick off the first build. 29 | 1. Open the new Bitrise project’s Workflow Editor. 30 | 1. Go to the **bitrise.yml** tab and replace the existing `bitrise.yml` with the contents of the example bitrise.yml below. 31 | 1. Click the **Start/Schedule a Build** button, and select the `build_and_run_tests` Pipeline option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 32 | 1. Open the Pipeline’s build page. 33 | 1. Select the `deploy_test_results` build. 34 | 1. Click on **Details & Add-ons** on the build details page and select the Test Reports add-on to view the merged test reports. 35 | 36 | ## bitrise.yml 37 | 38 | ```yaml 39 | --- 40 | format_version: '17' 41 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 42 | project_type: ios 43 | 44 | app: 45 | envs: 46 | - BITRISE_PROJECT_PATH: BullsEye.xcworkspace 47 | - BITRISE_SCHEME: BullsEye 48 | 49 | meta: 50 | bitrise.io: 51 | stack: osx-xcode-16.0.x 52 | machine_type_id: g2.mac.medium 53 | 54 | pipelines: 55 | build_and_run_tests: 56 | workflows: 57 | xcode_build_for_test: {} 58 | run_ui_tests: 59 | depends_on: [xcode_build_for_test] 60 | run_unit_tests: 61 | depends_on: [xcode_build_for_test] 62 | merge_and_deploy_test_results: 63 | depends_on: [run_ui_tests, run_unit_tests] 64 | 65 | workflows: 66 | xcode_build_for_test: 67 | steps: 68 | - git-clone@8: {} 69 | - xcode-build-for-test@3: 70 | inputs: 71 | - destination: generic/platform=iOS Simulator 72 | - deploy-to-bitrise-io@2: 73 | inputs: 74 | - pipeline_intermediate_files: "$BITRISE_TEST_BUNDLE_PATH:BITRISE_TEST_BUNDLE_PATH" 75 | 76 | run_ui_tests: 77 | before_run: 78 | - _pull_test_bundle 79 | steps: 80 | - xcode-test-without-building@0: 81 | inputs: 82 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_UITests_iphonesimulator15.2-arm64-x86_64.xctestrun" 83 | - destination: platform=iOS Simulator,name=iPhone 12 Pro Max 84 | - deploy-to-bitrise-io@2: 85 | inputs: 86 | - pipeline_intermediate_files: "$BITRISE_XCRESULT_PATH:BITRISE_UI_TEST_XCRESULT_PATH" 87 | 88 | run_unit_tests: 89 | before_run: 90 | - _pull_test_bundle 91 | steps: 92 | - xcode-test-without-building@0: 93 | inputs: 94 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_UnitTests_iphonesimulator15.2-arm64-x86_64.xctestrun" 95 | - destination: platform=iOS Simulator,name=iPhone 12 Pro Max 96 | - deploy-to-bitrise-io@2: 97 | inputs: 98 | - pipeline_intermediate_files: "$BITRISE_XCRESULT_PATH:BITRISE_UNIT_TEST_XCRESULT_PATH" 99 | 100 | merge_and_deploy_test_results: 101 | steps: 102 | - pull-intermediate-files@1: 103 | inputs: 104 | - artifact_sources: .* 105 | - script@1: 106 | inputs: 107 | - content: | 108 | #!/usr/bin/env bash 109 | set -eo pipefail 110 | 111 | for item in "${BITRISE_UI_TEST_XCRESULT_PATH}" "${BITRISE_UNIT_TEST_XCRESULT_PATH}"; 112 | do 113 | echo "Exporting ${item}" 114 | 115 | test_name=$(basename "$item" .xcresult) 116 | echo "Test name: $test_name" 117 | 118 | test_dir="${BITRISE_TEST_RESULT_DIR}/${test_name}" 119 | mkdir -p "${test_dir}" 120 | echo "Moving test result to: ${test_dir}" 121 | cp -R "${item}" "${test_dir}/$(basename ${item})" 122 | 123 | test_info="${test_dir}/test-info.json" 124 | echo "Creating Test info at: ${test_info}" 125 | echo "{ \"test-name\": \"${test_name}\" }" > "$test_info" 126 | done 127 | - deploy-to-bitrise-io@2: {} 128 | 129 | _pull_test_bundle: 130 | steps: 131 | - pull-intermediate-files@1: 132 | inputs: 133 | - artifact_sources: xcode_build_for_test 134 | ``` 135 | -------------------------------------------------------------------------------- /recipes/ios-merging-test-results-and-deploying-to-the-test-reports-add-on.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/ios-merging-test-results-and-deploying-to-the-test-reports-add-on.png -------------------------------------------------------------------------------- /recipes/ios-nightly-workflow.md: -------------------------------------------------------------------------------- 1 | # (iOS) Example Nightly Workflow 2 | 3 | ## Description 4 | 5 | Example Workflow for nightly builds for iOS apps. The Workflow contains: 6 | 7 | 1. Installing [Cocoapods](/recipes/ios-key-cache-cocoapods.md) and [Carthage](/recipes/ios-install-carthage-dependencies.md) dependecies. 8 | 2. [Setting the version and build number](https://www.bitrise.io/integrations/steps/set-ios-version). By default, the app will get the build number (`$BITRISE_BUILD_NUMBER`) as the version code. 9 | 3. [Building a release build and uploading to TestFlight](/recipes/ios-deploy-to-appstore.md). 10 | 4. [Building a test app and uploading to bitrise.io](/recipes/ios-deploy-to-bitrise.md). 11 | 5. [Sending the QR code of the test build to Slack](/recipes/slack-send-qr-code.md). 12 | 13 | Check out the [guide](https://devcenter.bitrise.io/en/builds/starting-builds/scheduling-builds.html) to run scheduled builds. 14 | 15 | ## bitrise.yml 16 | 17 | ```yaml 18 | --- 19 | format_version: '17' 20 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 21 | project_type: ios 22 | 23 | meta: 24 | bitrise.io: 25 | stack: osx-xcode-16.0.x 26 | machine_type_id: g2.mac.medium 27 | 28 | workflows: 29 | nightly: 30 | steps: 31 | - activate-ssh-key@4: 32 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 33 | - git-clone@8: {} 34 | - cocoapods-install@2: {} 35 | - carthage@3: 36 | inputs: 37 | - carthage_options: "--use-xcframeworks --platform iOS" 38 | - set-xcode-build-number@2: 39 | inputs: 40 | - build_short_version_string: '1.0' 41 | - xcode-archive@5: 42 | inputs: 43 | - project_path: $BITRISE_PROJECT_PATH 44 | - scheme: $BITRISE_SCHEME 45 | - automatic_code_signing: apple-id 46 | - distribution_method: app-store 47 | - deploy-to-itunesconnect-application-loader@1: 48 | inputs: 49 | - connection: apple_id 50 | - xcode-archive@5: 51 | inputs: 52 | - project_path: $BITRISE_PROJECT_PATH 53 | - scheme: $BITRISE_SCHEME 54 | - automatic_code_signing: apple-id 55 | - distribution_method: development 56 | - deploy-to-bitrise-io@2: {} 57 | - deploy-to-bitrise-io@2: {} 58 | - create-install-page-qr-code@1: {} 59 | - slack@4: 60 | inputs: 61 | - channel: "#build-notifications" 62 | - thumb_url: $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL 63 | - webhook_url: $SLACK_WEBHOOK 64 | 65 | app: 66 | envs: 67 | - BITRISE_PROJECT_PATH: BitriseTest.xcworkspace 68 | opts: 69 | is_expand: false 70 | - BITRISE_SCHEME: BitriseTest 71 | opts: 72 | is_expand: false 73 | - BITRISE_DISTRIBUTION_METHOD: development 74 | opts: 75 | is_expand: false 76 | ``` 77 | 78 | ## Relevant Links 79 | 80 | * https://devcenter.bitrise.io/en/builds/starting-builds/scheduling-builds.html 81 | -------------------------------------------------------------------------------- /recipes/ios-pull-request-workflow.md: -------------------------------------------------------------------------------- 1 | # (iOS) Example Pull Request Workflow 2 | 3 | ## Description 4 | 5 | Example Workflow for iOS Pull Request validation. The Workflow contains: 6 | 7 | 1. Installing [Cocoapods](/recipes/ios-key-cache-cocoapods.md) and [Carthage](/recipes/ios-install-carthage-dependencies.md) dependecies. 8 | 2. [Running all unit and UI tests on simulator](/recipes/ios-simulator-test.md) 9 | 3. [Building a test app and uploading to bitrise.io](/recipes/ios-deploy-to-bitrise.md) 10 | 4. [Sending the QR code of the test build to the Pull Request](/recipes/github-pull-request-build-qr-code.md) 11 | 5. Triggering the workflow for Pull Requests. 12 | 13 | ## bitrise.yml 14 | 15 | ```yaml 16 | --- 17 | format_version: '17' 18 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 19 | project_type: ios 20 | 21 | meta: 22 | bitrise.io: 23 | stack: osx-xcode-16.0.x 24 | machine_type_id: g2.mac.medium 25 | 26 | workflows: 27 | pull-request: 28 | steps: 29 | - activate-ssh-key@4: 30 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 31 | - git-clone@8: {} 32 | - restore-cocoapods-cache@2: {} 33 | - cocoapods-install@2: {} 34 | - restore-carthage-cache@2: {} 35 | - carthage@3: 36 | inputs: 37 | - carthage_options: "--use-xcframeworks --platform iOS" 38 | - restore-spm-cache@2: {} 39 | - xcode-test@5: 40 | inputs: 41 | - log_formatter: xcodebuild 42 | - xcodebuild_options: "-enableCodeCoverage YES" 43 | - xcode-archive@5: 44 | inputs: 45 | - project_path: $BITRISE_PROJECT_PATH 46 | - scheme: $BITRISE_SCHEME 47 | - automatic_code_signing: apple-id 48 | - distribution_method: development 49 | - deploy-to-bitrise-io@2: {} 50 | - create-install-page-qr-code@1: {} 51 | - comment-on-github-pull-request@0: 52 | inputs: 53 | - body: |- 54 | ![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) 55 | 56 | $BITRISE_PUBLIC_INSTALL_PAGE_URL 57 | - personal_access_token: $GITHUB_ACCESS_TOKEN 58 | - save-carthage-cache@1: {} 59 | - save-cocoapods-cache@1: {} 60 | - save-spm-cache@1: {} 61 | 62 | app: 63 | envs: 64 | - opts: 65 | is_expand: false 66 | BITRISE_PROJECT_PATH: BitriseTest.xcworkspace 67 | - opts: 68 | is_expand: false 69 | BITRISE_SCHEME: BitriseTest 70 | - opts: 71 | is_expand: false 72 | BITRISE_DISTRIBUTION_METHOD: development 73 | 74 | trigger_map: 75 | - pull_request_source_branch: "*" 76 | workflow: pull-request 77 | ``` 78 | -------------------------------------------------------------------------------- /recipes/ios-release-workflow.md: -------------------------------------------------------------------------------- 1 | # (iOS) Example Release Workflow 2 | 3 | ## Description 4 | 5 | Example Workflow for uploading a release draft of an iOS app to the App Store. The Worklow contains: 6 | 7 | 1. Installing [Cocoapods](/recipes/ios-key-cache-cocoapods.md) and [Carthage](/recipes/ios-install-carthage-dependencies.md) dependecies. 8 | 2. [Setting the version number](https://www.bitrise.io/integrations/steps/set-ios-version) based on [env vars passed to build](https://devcenter.bitrise.io/en/builds/environment-variables.html#setting-a-custom-env-var-when-starting-a-build) (`$VERSION_NUMBER`). 9 | 3. [Building a release build and uploading to App Store](/recipes/ios-deploy-to-appstore.md). 10 | 11 | ## bitrise.yml 12 | 13 | ```yaml 14 | --- 15 | format_version: '17' 16 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 17 | project_type: ios 18 | 19 | meta: 20 | bitrise.io: 21 | stack: osx-xcode-16.0.x 22 | machine_type_id: g2.mac.medium 23 | 24 | workflows: 25 | release: 26 | steps: 27 | - activate-ssh-key@4: 28 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 29 | - git-clone@8: {} 30 | - restore-cocoapods-cache@2: {} 31 | - carthage@3: 32 | inputs: 33 | - carthage_options: "--use-xcframeworks --platform iOS" 34 | - set-xcode-build-number@2: 35 | inputs: 36 | - build_short_version_string: $VERSION_NUMBER 37 | - recreate-user-schemes@1: 38 | inputs: 39 | - project_path: $BITRISE_PROJECT_PATH 40 | - xcode-archive@5: 41 | inputs: 42 | - project_path: $BITRISE_PROJECT_PATH 43 | - scheme: $BITRISE_SCHEME 44 | - automatic_code_signing: apple-id 45 | - distribution_method: app-store 46 | - deploy-to-itunesconnect-application-loader@1: 47 | inputs: 48 | - connection: apple_id 49 | 50 | app: 51 | envs: 52 | - BITRISE_PROJECT_PATH: BitriseTest.xcworkspace 53 | opts: 54 | is_expand: false 55 | - BITRISE_SCHEME: BitriseTest 56 | opts: 57 | is_expand: false 58 | - BITRISE_DISTRIBUTION_METHOD: development 59 | opts: 60 | is_expand: false 61 | ``` 62 | 63 | ## Relevant Links 64 | 65 | * https://devcenter.bitrise.io/en/builds/environment-variables.html#setting-a-custom-env-var-when-starting-a-build 66 | -------------------------------------------------------------------------------- /recipes/ios-run-test-groups-in-parallel.md: -------------------------------------------------------------------------------- 1 | # (iOS) Run test groups in parallel 2 | 3 | ## Description 4 | 5 | This example uses the [sample-swift-project-with-parallel-ui-test](https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) iOS Open Source sample app, which has some example Unit and UI tests and uses Test Plans to group the tests. 6 | 7 | **Note**: Xcode Test Plans provide a way to run a collection of tests with different test configurations. raywenderlich.com has a great [tutorial on how to get started with Xcode Test Plans](https://www.raywenderlich.com/10212963-xcode-test-plans-for-ios-getting-started). 8 | 9 | The example Pipeline config showcases how to run different test groups in parallel. 10 | 11 | `build_and_run_tests` pipeline's Workflows can be split into two logical groups: 12 | 1. Build tests: The `xcode_build_for_test` Workflow git clones the sample project and runs the `xcode-build-for-test` Step to build the target and associated tests. The built test bundle is shared with the following Workflows via the `deploy-to-bitrise-io` Step. 13 | 1. Run tests: Then two Workflows run in parallel: `run_ui_tests` and `run_unit_tests`. Both of these Workflows use the new `xcode-test-without-building` Step, which executes the tests based on the previous Workflow built test bundle. The pre-built test bundle is pulled by the `_pull_test_bundle` utility Workflow. 14 | 15 | ![A screenshot of the example Pipeline in Bitrise's web UI](./ios-run-test-groups-in-parallel.png) 16 | 17 | ## Instructions 18 | 19 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 20 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test`) in the **Git repository (clone) URL** field. 21 | 1. Confirm that this is a public repository in the resulting pop-up. 22 | 1. Select the `master` branch to scan. 23 | 1. Wait for the project scanner to complete. 24 | 1. Select any of the offered Distribution methods (for example development, it does not really matter as now we are focusing on testing). 25 | 1. Confirm the offered stack, skip choosing the app icon and the webhook registration and kick off the first build. 26 | 1. Open the new Bitrise project’s Workflow Editor. 27 | 1. Go to the **bitrise.yml** tab and replace the existing `bitrise.yml` with the contents of the example bitrise.yml below. 28 | 1. Click the **Start/Schedule a Build** button, and select the `build_and_run_tests` Pipeline option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 29 | 30 | 31 | ## bitrise.yml 32 | 33 | ```yaml 34 | --- 35 | format_version: '17' 36 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 37 | project_type: ios 38 | 39 | app: 40 | envs: 41 | - BITRISE_PROJECT_PATH: BullsEye.xcworkspace 42 | - BITRISE_SCHEME: BullsEye 43 | 44 | meta: 45 | bitrise.io: 46 | stack: osx-xcode-16.0.x 47 | machine_type_id: g2.mac.medium 48 | 49 | pipelines: 50 | build_and_run_tests: 51 | workflows: 52 | xcode_build_for_test: {} 53 | run_ui_tests: 54 | depends_on: [xcode_build_for_test] 55 | run_unit_tests: 56 | depends_on: [xcode_build_for_test] 57 | 58 | workflows: 59 | xcode_build_for_test: 60 | steps: 61 | - git-clone@8: {} 62 | - xcode-build-for-test@3: 63 | inputs: 64 | - destination: generic/platform=iOS Simulator 65 | - deploy-to-bitrise-io@2: 66 | inputs: 67 | - pipeline_intermediate_files: "$BITRISE_TEST_BUNDLE_PATH:BITRISE_TEST_BUNDLE_PATH" 68 | 69 | run_ui_tests: 70 | before_run: 71 | - _pull_test_bundle 72 | steps: 73 | - xcode-test-without-building@0: 74 | inputs: 75 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_UITests_iphonesimulator15.2-arm64-x86_64.xctestrun" 76 | - destination: platform=iOS Simulator,name=iPhone 12 Pro Max 77 | 78 | run_unit_tests: 79 | before_run: 80 | - _pull_test_bundle 81 | steps: 82 | - xcode-test-without-building@0: 83 | inputs: 84 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_UnitTests_iphonesimulator15.2-arm64-x86_64.xctestrun" 85 | - destination: platform=iOS Simulator,name=iPhone 12 Pro Max 86 | 87 | _pull_test_bundle: 88 | steps: 89 | - pull-intermediate-files@1: 90 | inputs: 91 | - artifact_sources: xcode_build_for_test 92 | ``` 93 | -------------------------------------------------------------------------------- /recipes/ios-run-test-groups-in-parallel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/ios-run-test-groups-in-parallel.png -------------------------------------------------------------------------------- /recipes/ios-run-tests-in-parallel-on-multiple-simulators.md: -------------------------------------------------------------------------------- 1 | # (iOS) Run tests in parallel on multiple simulators 2 | 3 | ## Description 4 | 5 | This example uses the [sample-swift-project-with-parallel-ui-test](https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) iOS Open Source sample app, which has some example Unit and UI tests and uses Test Plans to group the tests. 6 | 7 | The example Pipeline config showcases how to run all the test cases of the project on different iOS simulators. 8 | 9 | `build_and_run_tests` pipeline's Workflows can be split into two logical groups: 10 | 1. Build tests: The `xcode_build_for_test` Workflow git clones the sample project and runs the `xcode-build-for-test` Step to build the target and associated tests. The built test bundle is shared with the other workflows via the `deploy-to-bitrise-io` Step. 11 | 12 | **Note**: `xcode-build-for-test` Step compresses the built test bundle and moves the generated zip to the `$BITRISE_DEPLOY_DIR`, that directory’s content is deployed to the Workflow artifacts by default via the `deploy-to-bitrise-io` Step. 13 | 14 | 1. Run tests: Three Workflows are exsted in parallel: `run_tests_on_iPhone`, `run_tests_on_iPad`, and `run_tests_on_iPod`. All of these Workflows use the new `xcode-test-without-building` Step, which executes the tests based on the test bundle built by the previous workflow. The pre-built test bundle is pulled by the `_pull_test_bundle` utility Workflow. 15 | 16 | ![A screenshot of the example Pipeline in Bitrise's web UI](./ios-run-tests-in-parallel-on-multiple-simulators.png) 17 | 18 | ## Instructions 19 | 20 | 1. Visit the [Create New App page](https://app.bitrise.io/apps/add) to create a new App. 21 | 1. When prompted to select a git repository, choose **Other/Manual** and paste the sample project repository URL (`https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test`) in the **Git repository (clone) URL** field. 22 | 1. Confirm that this is a public repository in the resulting pop-up. 23 | 1. Select the `master` branch to scan. 24 | 1. Wait for the project scanner to complete. 25 | 1. Select any of the offered Distribution methods (for example development, it does not really matter as now we are focusing on testing). 26 | 1. Confirm the offered stack, skip choosing the app icon and the webhook registration and kick off the first build. 27 | 1. Open the new Bitrise project’s Workflow Editor. 28 | 1. Go to the **bitrise.yml** tab and replace the existing `bitrise.yml` with the contents of the example bitrise.yml below. 29 | 1. Click the **Start/Schedule a Build** button, and select the `build_and_run_tests` option in the **Workflow, Pipeline** dropdown menu at the bottom of the popup. 30 | 31 | 32 | ## bitrise.yml 33 | 34 | ```yaml 35 | --- 36 | format_version: '17' 37 | default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 38 | project_type: ios 39 | 40 | app: 41 | envs: 42 | - BITRISE_PROJECT_PATH: BullsEye.xcworkspace 43 | - BITRISE_SCHEME: BullsEye 44 | 45 | meta: 46 | bitrise.io: 47 | stack: osx-xcode-16.0.x 48 | machine_type_id: g2.mac.medium 49 | 50 | pipelines: 51 | build_and_run_tests: 52 | workflows: 53 | xcode_build_for_test: {} 54 | run_tests_on_iPhone: 55 | depends_on: [xcode_build_for_test] 56 | run_tests_on_iPad: 57 | depends_on: [xcode_build_for_test] 58 | run_tests_on_iPod: 59 | depends_on: [xcode_build_for_test] 60 | 61 | workflows: 62 | xcode_build_for_test: 63 | steps: 64 | - git-clone@8: {} 65 | - xcode-build-for-test@3: 66 | inputs: 67 | - destination: generic/platform=iOS Simulator 68 | - deploy-to-bitrise-io@2: 69 | inputs: 70 | - pipeline_intermediate_files: "$BITRISE_TEST_BUNDLE_PATH:BITRISE_TEST_BUNDLE_PATH" 71 | 72 | run_tests_on_iPhone: 73 | before_run: 74 | - _pull_test_bundle 75 | steps: 76 | - xcode-test-without-building@0: 77 | inputs: 78 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_FullTests_iphonesimulator15.2-arm64-x86_64.xctestrun" 79 | - destination: platform=iOS Simulator,name=iPhone 12 Pro Max 80 | 81 | run_tests_on_iPad: 82 | before_run: 83 | - _pull_test_bundle 84 | steps: 85 | - xcode-test-without-building@0: 86 | inputs: 87 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_FullTests_iphonesimulator15.2-arm64-x86_64.xctestrun" 88 | - destination: platform=iOS Simulator,name=iPad (9th generation) 89 | 90 | run_tests_on_iPod: 91 | before_run: 92 | - _pull_test_bundle 93 | steps: 94 | - xcode-test-without-building@0: 95 | inputs: 96 | - xctestrun: "$BITRISE_TEST_BUNDLE_PATH/BullsEye_FullTests_iphonesimulator15.2-arm64-x86_64.xctestrun" 97 | - destination: platform=iOS Simulator,name=iPod touch (7th generation) 98 | 99 | _pull_test_bundle: 100 | steps: 101 | - pull-intermediate-files@1: 102 | inputs: 103 | - artifact_sources: xcode_build_for_test 104 | ``` 105 | -------------------------------------------------------------------------------- /recipes/ios-run-tests-in-parallel-on-multiple-simulators.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitrise-io/workflow-recipes/ea4636bf4d122f44086d378dd53812f3cb089226/recipes/ios-run-tests-in-parallel-on-multiple-simulators.png -------------------------------------------------------------------------------- /recipes/ios-simulator-test.md: -------------------------------------------------------------------------------- 1 | # (iOS) Run tests on a simulator 2 | 3 | ## Description 4 | 5 | Run unit or UI tests of an iOS app on a simulator. 6 | 7 | ## Instructions 8 | 9 | 1. Add an [Xcode Test for iOS](https://bitrise.io/integrations/steps/xcode-test) Step. Override any of the following inputs if needed: 10 | - **Project path**: The default value is `$BITRISE_PROJECT_PATH` and in most cases you don't have to change it. 11 | - **Scheme**: The default value is `$BITRISE_SCHEME`, this variable stores the scheme that you set when adding the app on Bitrise. You can specify a different scheme if you want but it must be a shared scheme. 12 | - **Device destination specifier** (default: `platform=iOS Simulator,name=iPhone 8 Plus,OS=latest`). 13 | 2. Add a [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) Step that makes the test results available in the [Test Reports add-on](https://devcenter.bitrise.io/en/testing/test-reports.html). The failed tests will be also available under the `Test Results` tab on the build details page. 14 | 15 | ## bitrise.yml 16 | 17 | ```yaml 18 | - xcode-test@5: {} 19 | - deploy-to-bitrise-io@2: {} 20 | ``` 21 | -------------------------------------------------------------------------------- /recipes/key-cache-advanced.md: -------------------------------------------------------------------------------- 1 | # Advanced key-based cache recipes 2 | 3 | These workflow recipes are based on the **Save cache** and **Restore cache** Steps. 4 | 5 | For recipes about the most popular platforms and dependency managers, check out the **Key-based caching** section in the [README](../README.md). 6 | 7 | ## Key templates 8 | 9 | The **Save cache** and **Restore cache** Steps use a string key when uploading and downloading a cache archive. To always download the most relevant cache archive for each build, the **Cache key** input can contain template elements. The Steps evaluate the key template at runtime and the final key value can change based on the build environment or files in the repo. 10 | 11 | The following variables are supported in the **Cache key** input: 12 | 13 | - `cache-key-{{ .Branch }}`: Current git branch the build runs on 14 | - `cache-key-{{ .CommitHash }}`: SHA-256 hash of the git commit the build runs on 15 | - `cache-key-{{ .Workflow }}`: Current Bitrise workflow name (eg. `primary`) 16 | - `{{ .Arch }}-cache-key`: Current CPU architecture (`amd64` or `arm64`) 17 | - `{{ .OS }}-cache-key`: Current operating system (`linux` or `darwin`) 18 | 19 | Functions available in a template: 20 | 21 | `checksum`: This function takes one or more file paths and computes the SHA256 [checksum](https://en.wikipedia.org/wiki/Checksum) of the file contents. This is useful for creating unique cache keys based on files that describe content to cache. 22 | 23 | Examples of using `checksum`: 24 | - `cache-key-{{ checksum "package-lock.json" }}` 25 | - `cache-key-{{ checksum "**/Package.resolved" }}` 26 | - `cache-key-{{ checksum "**/*.gradle*" "gradle.properties" }}` 27 | 28 | `getenv`: This function returns the value of an environment variable or an empty string if the variable is not defined. 29 | 30 | Examples of `getenv`: 31 | - `cache-key-{{ getenv "PR" }}` 32 | - `cache-key-{{ getenv "BITRISEIO_PIPELINE_ID" }}` 33 | 34 | ## Skip saving the cache in PR builds (restore only) 35 | 36 | If you want builds triggered by pull requests to only restore the cache and skip saving it, you can run the **Save cache** Step conditionally: 37 | 38 | ```yaml 39 | steps: 40 | - restore-cache@2: 41 | inputs: 42 | - key: node-modules-{{ checksum "package-lock.json" }} 43 | 44 | # Build steps 45 | 46 | - save-cache@1: 47 | run_if: ".IsCI | and (not .IsPR)" # Condition that is false in PR builds 48 | inputs: 49 | - key: node-modules-{{ checksum "package-lock.json" }} 50 | - paths: node_modules 51 | ``` 52 | 53 | ## Separate caches for each OS and architecture 54 | 55 | Cache is not guaranteed to work across different Bitrise Stacks (different OS or same OS but different CPU architecture). If a Workflow runs on different stacks, it's a good idea to include the OS and architecture in the **Cache key** input: 56 | 57 | ```yaml 58 | steps: 59 | - save-cache@1: 60 | inputs: 61 | - key: '{{ .OS }}-{{ .Arch }}-npm-cache-{{ checksum "package-lock.json" }}' 62 | - path: node_modules 63 | ``` 64 | 65 | ## Multiple independent caches 66 | 67 | You can add multiple instances of the cache steps to a Workflow: 68 | 69 | ```yaml 70 | steps: 71 | - save-cache@1: 72 | title: Save NPM cache 73 | inputs: 74 | - paths: node_modules 75 | - key: npm-cache-{{ checksum "package-lock.json" }} 76 | - save-cache@1: 77 | title: Save Python cache 78 | inputs: 79 | - paths: venv/ 80 | - key: pip-cache-{{ checksum "requirements.txt" }} 81 | ``` 82 | 83 | ## Cache warm-up for pull requests 84 | 85 | Caching works best when the cached content is up to date and contains useful data for dependency managers and build systems. It's a good idea to run a Workflow periodically that builds the project from the latest code on the main branch and saves the result in the cache. This way, other builds triggered by pull requests can restore an up-to-date cache. 86 | 87 | By including a checksum in the **Cache key** input, the **Save cache** Step will save multiple unique cache archives when the project files change (instead of overriding the previous cache). This way PRs not targeting the latest state of the main branch can still download a relevant cache archive. 88 | 89 | ```yaml 90 | workflows: 91 | pr-validation: 92 | steps: 93 | - restore-cache@2: 94 | inputs: 95 | - key: |- 96 | node-modules-{{ checksum "package-lock.json" }} 97 | node-modules- 98 | # Rest of the PR validation workflow 99 | 100 | cache-warm-up: 101 | description: This Workflow should either be run on a scheduled basis or triggered by a push event on the main branch. 102 | steps: 103 | # Build steps 104 | - save-cache@1: 105 | inputs: 106 | - key: node-modules-{{ checksum "package-lock.json" }} 107 | - paths: node_modules/ 108 | ``` 109 | 110 | ## Restore cache from the PR target branch 111 | 112 | If you have a setup where the cache key is based on the current workflow (such as `cache-{{ .Workflow }}`), then you can configure the Restore Step with the following keys: 113 | 114 | ``` 115 | cache-{{ .Workflow }} 116 | cache-{{ getenv "BITRISEIO_GIT_BRANCH_DEST" }} 117 | cache- 118 | ``` 119 | 120 | The keys listed in the step input are processed in priority order. If there is a cache entry for the exact same branch, the first rule will match that. You can also compute the cache key of the pull requests's target branch (such as `main` or `trunk`) via the `BITRISEIO_GIT_BRANCH_DEST` env var, which is automatically set for PR builds. Restoring the cache from the target branch can be useful when there are multiple long-lived branches and PRs are targeting different branches. -------------------------------------------------------------------------------- /recipes/recipes.yml: -------------------------------------------------------------------------------- 1 | recipes: 2 | - file: 'recipes/caching-npm-dependencies.md' 3 | name: 'Caching npm Dependencies' 4 | platforms: ['reactnative', 'cordova', 'ionic'] 5 | - file: 'recipes/upload-to-appstore.md' 6 | name: 'Upload to AppStore Connect / TestFlight' 7 | platforms: ['ios'] 8 | - file: 'recipes/send-qr-code-to-slack.md' 9 | name: 'Send QR code to Slack' 10 | platforms: [] 11 | - file: 'workflow-for-creating-a-gitflow-release-branch.md' 12 | name: 'Workflow for creating a Gitflow release branch' 13 | platforms: ['ios'] 14 | - file: 'recipes/running-workflows-in-parallel.md' 15 | name: 'Running workflows in parallel' 16 | platforms: [] 17 | - file: 'recipes/gradle-build-profiling.md' 18 | name: 'Turn on Gradle build profiling' 19 | platforms: ['android'] 20 | 21 | -------------------------------------------------------------------------------- /recipes/rn-expo-turtle-build.md: -------------------------------------------------------------------------------- 1 | # (React Native) Expo: Build using Turtle CLI 2 | 3 | ## Description 4 | 5 | Publish an app to Expo's servers and build an iOS App Store `.ipa` and Android `.aab` files from your Expo project using [Turtle CLI](https://docs.expo.dev/classic/turtle-cli/). 6 | 7 | ## Prerequisites 8 | 9 | 1. Generate an iOS Distribution Certificate and an App Store Provisioning Profile based on the [Generating iOS code signing files](https://devcenter.bitrise.io/en/code-signing/ios-code-signing/generating-ios-code-signing-files.html) guide. 10 | 2. Generate an Android Keystore by following the [Android code signing with Android Studio](https://devcenter.bitrise.io/en/code-signing/android-code-signing/android-code-signing-with-android-studio.html) guide. 11 | 3. Make sure you can [Publish your Expo project](https://docs.expo.dev/classic/turtle-cli/#publish-your-project) locally. 12 | 13 | ## Instructions 14 | 15 | 1. Upload the project's iOS Distribution Certificate and App Store Provisioning Profile on the Bitrise project's Workflow Editor / Code signing tab. 16 | 2. Upload the project's Android Keystore on the Bitrise project's Workflow Editor / Code signing tab. 17 | 3. Create a Secret (`IOS_DEVELOPMENT_TEAM`) with the ID of the iOS Development Team, issued the project's Certificate and Provisioning Profile. 18 | 4. Store the Expo account, used for publishing the Expo app and fetching the app manifest, in `EXPO_USERNAME` and `EXPO_PASSWORD` secrets. 19 | 5. Copy-paste `envs` from `bitrise.yml` below to your Workflow. 20 | 6. Copy-paste `steps` from `bitrise.yml` below to your Workflow. 21 | - The built `.ipa` and `.aab` files are exposed via `BITRISE_IPA_PATH` and `BITRISE_AAB_PATH` env vars. 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | turtle_build: 27 | envs: 28 | - KEYSTORE_PATH: /tmp/keystore.jks 29 | - KEYSTORE_ALIAS: $BITRISEIO_ANDROID_KEYSTORE_ALIAS 30 | - EXPO_ANDROID_KEYSTORE_PASSWORD: $BITRISEIO_ANDROID_KEYSTORE_PASSWORD 31 | - EXPO_ANDROID_KEY_PASSWORD: $BITRISEIO_ANDROID_KEYSTORE_PRIVATE_KEY_PASSWORD 32 | - PROFILE_PATH: /tmp/profile.mobileprovision 33 | - CERTIFICATE_PATH: /tmp/certificate.p12 34 | - EXPO_IOS_DIST_P12_PASSWORD: $BITRISE_CERTIFICATE_PASSPHRASE 35 | # Define these in your secrets 36 | - IOS_DEVELOPMENT_TEAM: $IOS_DEVELOPMENT_TEAM 37 | - EXPO_USERNAME: $EXPO_USERNAME 38 | - EXPO_PASSWORD: $EXPO_PASSWORD 39 | steps: 40 | - script@1: 41 | title: Install dependencies 42 | inputs: 43 | - content: |- 44 | #!/usr/bin/env bash 45 | set -ex 46 | 47 | node --version 48 | fastlane --version 49 | 50 | npm install -g turtle-cli 51 | turtle --version 52 | 53 | npm install -g expo-cli 54 | expo --version 55 | - file-downloader@1: 56 | title: Download Android Keystore 57 | inputs: 58 | - destination: $KEYSTORE_PATH 59 | - source: $BITRISEIO_ANDROID_KEYSTORE_URL 60 | - file-downloader@1: 61 | title: Download iOS Certificate 62 | inputs: 63 | - destination: $CERTIFICATE_PATH 64 | - source: $BITRISE_CERTIFICATE_URL 65 | - file-downloader@1: 66 | title: Download iOS Provisioning Profile 67 | inputs: 68 | - destination: $PROFILE_PATH 69 | - source: $BITRISE_PROVISION_URL 70 | - npm@1: 71 | title: Install project dependencies 72 | inputs: 73 | - command: install 74 | - set-java-version@1: 75 | title: Set Java version to Java 8 76 | inputs: 77 | - set_java_version: "8" 78 | - script@1: 79 | title: Run Expo publish 80 | inputs: 81 | - content: |- 82 | #!/usr/bin/env bash 83 | set -ex 84 | 85 | expo login -u $EXPO_USERNAME -p $EXPO_PASSWORD --non-interactive 86 | expo publish 87 | - script@1: 88 | title: Run Turtle build 89 | inputs: 90 | - content: |- 91 | #!/usr/bin/env bash 92 | set -ex 93 | 94 | turtle setup:android 95 | aab_path=$BITRISE_DEPLOY_DIR/expo-project.aab 96 | turtle build:android --type app-bundle --keystore-path $KEYSTORE_PATH --keystore-alias $KEYSTORE_ALIAS -o $aab_path 97 | envman add --key BITRISE_AAB_PATH --value $aab_path 98 | 99 | turtle setup:ios 100 | ipa_path=$BITRISE_DEPLOY_DIR/expo-project.ipa 101 | turtle build:ios --team-id $IOS_DEVELOPMENT_TEAM --dist-p12-path $CERTIFICATE_PATH --provisioning-profile-path $PROFILE_PATH -o $ipa_path 102 | envman add --key BITRISE_IPA_PATH --value $ipa_path 103 | ``` 104 | -------------------------------------------------------------------------------- /recipes/rn-install-dependencies.md: -------------------------------------------------------------------------------- 1 | # (React Native) Install dependencies 2 | 3 | ## Description 4 | Install dependencies using either yarn or npm. 5 | 6 | ## Instructions 7 | 8 | 1. Add either the [Run yarn command](https://www.bitrise.io/integrations/steps/yarn) or the [Run npm command](https://bitrise.io/integrations/steps/npm) Step based on your project setup. 9 | 2. Set the **The yarn command to run** or **The npm command with arguments to run** input to `install`. 10 | 11 | ## bitrise.yml 12 | 13 | Using `yarn`: 14 | ```yaml 15 | - yarn@0: 16 | inputs: 17 | - command: install 18 | ``` 19 | 20 | Using `npm`: 21 | ```yaml 22 | - npm@1: 23 | inputs: 24 | - command: install 25 | ``` 26 | -------------------------------------------------------------------------------- /recipes/rn-key-cache-dependencies.md: -------------------------------------------------------------------------------- 1 | # (React Native) Cache NPM dependencies (Beta) 2 | 3 | ## Description 4 | 5 | Cache the contents of the `node_modules` folder with the new key-based caching Steps, **Save Cache** and **Restore Cache**. 6 | 7 | ## Instructions 8 | 9 | 1. Add the [Restore NPM Cache](https://github.com/bitrise-steplib/bitrise-step-restore-npm-cache) Step to the Workflow. 10 | 1. Add either the [Run yarn command](https://www.bitrise.io/integrations/steps/yarn) Step or the [Run npm command](https://github.com/bitrise-steplib/steps-npm) Step based on your project setup. Set the input variables: 11 | - Set the **The yarn command to run** or **The npm command with arguments to run** input to `install`. 12 | 1. Add the [Save NPM Cache](https://github.com/bitrise-steplib/bitrise-step-save-npm-cache) Step. 13 | 14 | ### Fine tune cache behaviour 15 | 16 | The NPM specific cache steps use optimal cache key and path configurations maintained by Bitrise. If you want full control over what should be cached then please check out the generic [Restore Cache](https://github.com/bitrise-steplib/bitrise-step-restore-cache) and [Save Cache](https://github.com/bitrise-steplib/bitrise-step-save-cache) Steps. 17 | 18 | You can always check out what key and path settings the NPM cache step uses: 19 | [Github code snippet](https://github.com/bitrise-steplib/bitrise-step-save-npm-cache/blob/main/step/step.go#L13-L25) 20 | 21 | ## bitrise.yml 22 | 23 | ```yaml 24 | - restore-npm-cache@2: {} 25 | - npm@1: 26 | inputs: 27 | - command: install 28 | - save-npm-cache@1: {} 29 | ``` 30 | -------------------------------------------------------------------------------- /recipes/rn-tests.md: -------------------------------------------------------------------------------- 1 | # (React Native) Run tests 2 | 3 | ## Description 4 | 5 | Run tests (for example, Jest). 6 | 7 | ## Instructions 8 | 9 | 1. Add either the [Run yarn command](https://www.bitrise.io/integrations/steps/yarn) or the [Run npm command](https://bitrise.io/integrations/steps/npm) Step based on your project setup. 10 | 2. Set the **The yarn command to run** or **The npm command with arguments to run** input to `test`. 11 | 12 | ## bitrise.yml 13 | 14 | Using `yarn`: 15 | 16 | ```yaml 17 | - yarn@0: 18 | inputs: 19 | - command: test 20 | ``` 21 | 22 | Using `npm`: 23 | 24 | ```yaml 25 | - npm@1: 26 | inputs: 27 | - command: test 28 | ``` 29 | -------------------------------------------------------------------------------- /recipes/run-step-conditionally.md: -------------------------------------------------------------------------------- 1 | # Run a Step conditionally 2 | 3 | ## Description 4 | 5 | You can configure a Step to run only in specific circumstances. For details, please check [Enabling or disabling a Step conditionally](https://devcenter.bitrise.io/en/steps-and-workflows/enabling-or-disabling-a-step-conditionally.html). 6 | 7 | ## Relevant Links 8 | 9 | * https://devcenter.bitrise.io/en/steps-and-workflows/enabling-or-disabling-a-step-conditionally.html 10 | * https://devcenter.bitrise.io/en/references/available-environment-variables.html 11 | -------------------------------------------------------------------------------- /recipes/shallow-clone-repo.md: -------------------------------------------------------------------------------- 1 | # Shallow clone the git repository 2 | 3 | ## Description 4 | 5 | Speed up cloning the repository by specifying a clone depth. Keep in mind that in case of Pull Request you need to make sure that both the source and destination branch are available in the history. 6 | 7 | ## Instructions 8 | 9 | 1. Set the **Limit fetching to the specified number of commits** input variable: 10 | - In the case of builds running on a single branch you can set it to `1`. 11 | - In the case of Pull Request builds set it to a depth that will contain both the source and target branches. For example, `100`. 12 | 13 | ## bitrise.yml 14 | 15 | ```yaml 16 | - git-clone@8: 17 | inputs: 18 | - clone_depth: 1 19 | ``` 20 | 21 | ## Relevant Links 22 | 23 | * https://discuss.bitrise.io/t/git-clone-step-is-very-slow/3844/2 24 | * https://stackoverflow.com/questions/6941889/is-it-safe-to-shallow-clone-with-depth-1-create-commits-and-pull-updates-aga 25 | -------------------------------------------------------------------------------- /recipes/slack-send-build-status.md: -------------------------------------------------------------------------------- 1 | # (iOS/Android) Slack - send build status 2 | 3 | ## Description 4 | Sending a slack massage to Slack with the build status after a build has finished. 5 | 6 | ## Prerequisites 7 | 8 | 2. You have a Slack webhook set up and added to Env Vars (for example, `$SLACK_WEBHOOK`). For details, see [Configuring Slack integration](https://devcenter.bitrise.io/en/builds/configuring-build-settings/configuring-slack-integration.html) 9 | 10 | ## Instructions 11 | 12 | 1. Add the [Send a Slack message](https://www.bitrise.io/integrations/steps/slack) step. Set the input variables: 13 | - **Slack Webhook URL**: for example, `$SLACK_WEBHOOK`. 14 | - **Target Slack channel, group or username**: for example, `#build-notifications`. 15 | - Check out the other optional input variables in the Workflow Editor or in the Step description. 16 | 17 | ## bitrise.yml 18 | 19 | ```yaml 20 | - slack@4: 21 | inputs: 22 | - channel: "#build-notifications" 23 | - webhook_url: $SLACK_WEBHOOK 24 | ``` 25 | 26 | ## Relevant Links 27 | 28 | * https://devcenter.bitrise.io/en/builds/configuring-build-settings/configuring-slack-integration.html 29 | -------------------------------------------------------------------------------- /recipes/slack-send-qr-code.md: -------------------------------------------------------------------------------- 1 | # (iOS/Android) Send QR code to Slack 2 | 3 | ## Description 4 | Sending a QR code of the iOS or Android build uploaded to bitrise.io to Slack. 5 | 6 | ## Prerequisites 7 | 8 | 1. You have your iOS or Android app archived. 9 | 2. You have Slack webhook set up and added to Env Vars (for example, `$SLACK_WEBHOOK`). See [Configuring Slack integration](https://devcenter.bitrise.io/en/builds/configuring-build-settings/configuring-slack-integration.html) 10 | 11 | ## Instructions 12 | 13 | 1. Add the [Deploy to Bitrise.io - Apps, Logs, Artifacts](https://www.bitrise.io/integrations/steps/deploy-to-bitrise-io) step. 14 | 2. Add the [Create install page QR code](https://www.bitrise.io/integrations/steps/create-install-page-qr-code) step. 15 | 3. Add the [Send a Slack message](https://www.bitrise.io/integrations/steps/slack) step. Set the input variables: 16 | - **Slack Webhook URL**: for example, `$SLACK_WEBHOOK`. 17 | - **Target Slack channel, group or username**: for example, `#build-notifications`. 18 | - **A URL to an image file that will be displayed as a thumbnail**: `$BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL`. 19 | 20 | ## bitrise.yml 21 | 22 | ```yaml 23 | - deploy-to-bitrise-io@2: {} 24 | - create-install-page-qr-code@1: {} 25 | - slack@4: 26 | inputs: 27 | - channel: "#build-notifications" 28 | - thumb_url: $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL 29 | - webhook_url: $SLACK_WEBHOOK 30 | ``` 31 | 32 | ## Relevant Links 33 | 34 | * https://devcenter.bitrise.io/en/deploying/ios-deployment/deploying-an-ios-app-to-bitrise-io.html 35 | * https://devcenter.bitrise.io/en/deploying/android-deployment/deploying-android-apps-to-bitrise-and-google-play.html#deploying-an-android-app-to-bitrise-io-43303 36 | * https://devcenter.bitrise.io/en/builds/configuring-build-settings/configuring-slack-integration.html 37 | -------------------------------------------------------------------------------- /recipes/ssh-and-clone.md: -------------------------------------------------------------------------------- 1 | # Cloning the repository 2 | 3 | ## Description 4 | 5 | Clone a git repo. 6 | 7 | ## Instructions 8 | 9 | 1. Make sure that the Workflow has the [Activate SSH key (RSA private key)](https://bitrise.io/integrations/steps/activate-ssh-key) step. This allows the Git client on the build VM to access private repositories. 10 | 2. Add the [Git Clone Repository](https://bitrise.io/integrations/steps/git-clone) Step. 11 | - Check out the optional inputs in the Workflow Editor or in the Step documentation. 12 | 13 | ## bitrise.yml 14 | 15 | ```yaml 16 | - activate-ssh-key@4: 17 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 18 | - git-clone@8: {} 19 | ``` 20 | -------------------------------------------------------------------------------- /recipes/start-builds.md: -------------------------------------------------------------------------------- 1 | # Start (parallel) builds from the Workflow 2 | 3 | ## Description 4 | 5 | Start one or more builds with specified Workflows from the parent Workflow and optionally wait for their completion. 6 | 7 | ## Prerequisites 8 | 9 | 1. Make sure you have a valid Bitrise API key in your Secrets (`$BITRISE_API_KEY`). See [Personal access](https://devcenter.bitrise.io/en/accounts/personal-access-tokens.html##) tokens for more details. 10 | 2. Have Workflow(s) you would like to run in parallel (`workflow-1` and `workflow-2` in the example). 11 | 12 | ## Instructions 13 | 14 | 1. Add a [Bitrise Start Build](https://www.bitrise.io/integrations/steps/build-router-start) Step. Set the input variables: 15 | - **workflows**: The Workflow(s) to start. One Workflow per line. 16 | - **Bitrise Access Token**: `$BITRISE_API_KEY`. 17 | 2. (Optional) Add any Step you would like to run in parallel in the parent Workflow while the triggered Workflows are running. 18 | 3. (Optional) Add a [Bitrise Wait for Build](https://www.bitrise.io/integrations/steps/build-router-wait) Step. Set the input variables: 19 | - **Bitrise Access Token**: `$BITRISE_API_KEY` 20 | 21 | With the Steps above you can only start a build for the same app. If you would like to start a build for an other app, you can use the [Trigger Bitrise workflow](https://www.bitrise.io/integrations/steps/trigger-bitrise-workflow) Step. 22 | 23 | ## bitrise.yml 24 | 25 | ```yaml 26 | parent-workflow: 27 | steps: 28 | - build-router-start@0: 29 | inputs: 30 | - workflows: |- 31 | workflow-1 32 | workflow-2 33 | - access_token: $BITRISE_API_KEY 34 | - script@1: 35 | inputs: 36 | - content: echo "Doing something else..." 37 | - build-router-wait@0: 38 | inputs: 39 | - access_token: $BITRISE_API_KEY 40 | ``` 41 | -------------------------------------------------------------------------------- /recipes/workflow-create-gitflow-release-branch.md: -------------------------------------------------------------------------------- 1 | # Example Workflow: Create Gitflow release branch 2 | 3 | ## Description 4 | An example Workflow that creates a Gitflow release branch for a specific version. The version can be passed as an Environment Variable for the Workflow. 5 | 6 | ## Prerequisites 7 | 8 | Make sure that Bitrise has write access to your repository. You need to [manually add an SSH key](https://devcenter.bitrise.io/en/apps/configuring-ssh-keys.html#configuring-ssh-keys) with **write** permission on GitHub. 9 | 10 | ## bitrise.yml 11 | 12 | ```yaml 13 | # Run the workflow with $VERSION env set up to, for examepl, '2.4.3' 14 | create-release-branch: 15 | steps: 16 | - activate-ssh-key@4: 17 | run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 18 | - git-clone@8: {} 19 | - script@1: 20 | inputs: 21 | - content: |- 22 | #!/usr/bin/env bash 23 | # fail if any commands fails 24 | set -e 25 | # debug log 26 | set -x 27 | 28 | git checkout -b release-$VERSION 29 | git push origin release-$VERSION 30 | ``` 31 | --------------------------------------------------------------------------------