Types of automations
Runway will automatically create new Slack channel(s) for the release, if you have release-specific channels configured (e.g.
release-{version}) in settings.Visit the Notification settings article for additional information on configuring release-specific channels.
Runway detects where the app version is referenced in your code and bumps it according to your team's bump version strategy (configurable from settings for this automation):
- Pre-kickoff, to current release version, on working branch: Runway will bump the version on your working branch to the current release version prior to kicking off your release.
- Post-kickoff, to current release version, on release branch: Runway will bump the version on your release branch to the current release version once your current release has been kicked off.
- Post-kickoff, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version once your current release has been kicked off.
- Post-submission, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version as soon as your current release has been submitted for review.
- Post-release, to next version, on working branch: Runway will bump the version on your working branch to the next-up release version as soon as your current version has been released to the app store.
By default, Runway will detect the app version from your codebase by inspecting a handful of platform-specific files where versions are commonly found.
You can always configure an override list of version files in App Settings, which are not limited to any of the default file types and extensions.
The default file types that Runway will detect versions in are as follows:
iOS:
.pbxproj.xcconfig.plist.json.yaml
Android:
.gradle.json.yaml
React Native / OTA:
package.json
The table below describes the format (in regex) Runway is expecting to find the version in depending on the file type.
File type | Regular expression | Description | Example |
|---|---|---|---|
.pbxproj | MARKETING_VERSION = (\d+\.\d+\.\d+) | Matches the string MARKETING_VERSION = (case sensitive) followed by one or more digits separated by a . character | MARKETING_VERSION = 12.2.2 |
.xcconfig | MARKETING_VERSION = (\d+\.\d+\.\d+) | Matches the string MARKETING_VERSION = (case sensitive) followed by one or more digits separated by a . character | MARKETING_VERSION = 12.2.2 |
.plist | CFBundleShortVersionString<\/key>\s*<string>(\d+\.\d+\.\d+)<\/string> | Matches the CFBundleShortVersionString</key> string (case sensitive) followed by zero or more white space characters (spaces, tabs, line breaks), followed by the <string> string, followed by one or more digits separated by a . character, followed by the </string> string | CFBundleShortVersionString</key><string>2.2.2</string> |
.yaml | version:\s+?(\d+\.\d+\.\d+) | Matches the version: string, followed by one or more white space characters (spaces, tabs, line breaks), followed by one or more digits separated by a . character | version: 12.2.2 |
.gradle | versionName.*?(\d+\.\d+\.\d+)|versionString.*?(\d+\.\d+\.\d+) | Matches the versionName string, followed by zero or more of any character (except line breaks), followed by one or more digits separated by a . character OR the string versionString, followed by zero or more of any character (except line breaks), followed by one or more digits separated by a . character | versionName 12.2.2 |
.json | \"version\":\s+?\"(\d+\.\d+\.\d+)\" | Matches the "version": string (case sensitive), followed by one or more white space characters (spaces, tabs, line breaks), followed by the one or more digits separated by a . character wrapped in quotation marks | "version": "12.2.2" |
Default (all other file types) | (\d+\.\d+\.\d+) | Matches one or more digits separated by a . character | 12.2.2 |
Runway will promote code from your working branch to your release branch on the scheduled date.
You may be required to approve and merge the resulting pull request depending on your VCS settings, and on whether you have the "Merge pull requests opened by Runway" automation enabled.
Runway will create a release branch off of your working branch for the next release on the scheduled date.
This automation will always be inactive for hotfix releases in Runway.
Runway will submit your selected build for review on the scheduled target submit date if all previous steps are ready (green).
If automated submission fails, Runway will attempt to submit again every 5 minutes up to a maximum of 5 times. After that, you'll need to update to a future target submit date or release your update manually.
This automation will always be inactive for hotfix releases in Runway.
Runway will release your app update (or start your phased release, if applicable) on the scheduled target release date if all previous steps are ready (green) and your app update has passed App Store review.
If automated release fails, Runway will attempt to release again every 5 minutes up to a maximum of 5 times. After that, you'll need to update to a future target release date, or release your update manually.
This automation will always be inactive for hotfix releases in Runway.
Runway will release your update to all users early if the release is healthy and has met the predefined conditions.
This automation is not available for OTA apps.
This automation can be configured with:
- One or more health metrics. Only releases whose health metrics are all healthy will trigger an early release to all users.
- At least one condition (such as minimum adoption threshold and minimum phased release day or staged rollout percentage). Only releases that have met the configured conditions will trigger an early release to all users.
You must configure at least one condition and one associated health metric for this automation.
Only releases that have met the configured conditions, and whose associated health metrics are healthy will trigger the automation to release to all users early.
When multiple AABs or APKs are associated with a given Android release version, Runway will look at health metrics for all builds — all must be within a ‘healthy’ threshold and must have met the configured conditions for the automation to trigger.
Runway will halt your phased release / staged rollout if if any associated health metrics fall outside of their defined thresholds.
This automation is not available for OTA apps.
This automation can be configured with:
- One or more health metrics. Any health metrics that fall outside of their defined thresholds will trigger the automation.
- At least one condition (such as minimum adoption threshold and minimum phased release day or staged rollout percentage). Only releases that have met the configured conditions will trigger a halt to the release.
You must configure at least one condition and one associated health metric for this automation.
Only releases that have met the configured conditions, and whose associated health metrics are healthy will trigger the automation to release to all users early.
When multiple AABs or APKs are associated with a given Android release version, Runway will look at health metrics for all builds — any builds with "unhealthy" health metrics will trigger the halt automation as long as all required conditions have been met.
At the end of the release cycle, Runway will merge the release branch back into the working branch (and any existing open release branches) if it detects commits on the release branch that are not on the working branch.
Runway will delete version-specific release branches when the release is complete and tagged.
This automation is only intended for use by teams that use version-specific release branches.
Runway will cherry-pick commits from PRs that contain the specified text pattern in their title from the working branch into the desired release branch.
You can configure the text pattern that Runway will look for in the automation's settings modal (e.g.
runway-pick-{version}). If the text pattern contains the tokens {version} or {versionConcise}, work will be cherry-picked onto the release branch for the version specified. If the text pattern does not contain a version-specific token, tagged work will be cherry-picked into the next active release version. Note that the target release version must be kicked off in order for tagged work to be pulled in.Runway will always open a pull request with the cherry-picked commits against the target release branch.
If the merge pull requests opened by Runway automation is enabled, Runway will attempt to automatically merge the PR once possible (e.g. when all blocking checks have passed).
Runway will create a new version of your app in App Store Connect once the next release is being prepared in Runway.
Runway will create a draft production release in the Play Console for the current release in Runway if needed, and keep the version name in sync if the version changes in Runway.
Runway will apply your default Export Compliance Information answers (as defined in App Settings) to new builds as they are uploaded to App Store Connect.
Runway will select the latest available build for release in App Store Connect. Note that there may be a processing delay of a few minutes.
Runway will select the latest available APK/AAB in the production track in the Play Console.
Runway will stop performing this automation when:
- a different build is manually selected in App Store Connect / Play Console
- a different build is manually selected in Runway's submission step
- an RC build is manually selected as Active RC in Runway's Release candidate step, and that RC build has an associated app store build
Runway will apply your default 'What's New' text (as defined in App Settings) to new versions created in App Store Connect. You can continue to modify the text before you submit your update for review.
Runway will apply your default release notes (as defined in App Settings) to new versions created in the Play Console. You can continue to modify the text before you submit your update for review.
Runway will automatically download dSYM files for all builds in App Store Connect and then upload them to your stability monitoring platform. Not applicable if bitcode is disabled.
Currently available for teams with Sentry and Bugsnag integrations only; we hope to add Firebase support soon.
When submitting a new release for review, Runway will apply your default file attachment provided for reviewers (as defined in App Settings) to new versions created in App Store Connect.
Runway will promote any newly uploaded APKs/AABs to your testing track and start the rollout.
Runway will assign any new builds uploaded to TestFlight to your default beta groups for testing. External testers will have access once the build has been reviewed.
Runway will submit any new builds uploaded to TestFlight for beta review as soon as they finish processing.
Runway will automatically carry over the 'What to Test' notes of the previous TestFlight build to new builds.
Runway will automatically carry over the Release Notes of the previous beta build to new builds.
Runway will tag your production release commit at the end of each release cycle, and generate a summary of all work going out with the release. The summary will be added to a "Release" in your VCS integration, and will include a list of commits and their associated project management tickets.
Release in GitHub created by Runway
Your previous release must be tagged in order for Runway to accurately compute the summary of work for a release.
Runway may fail to tag your releases automatically in certain cases:
- Your previous release was not tagged
- The build that was released could not be associated with a Release Candidate (CI) build, and therefore could not be linked to a specific commit in your VCS
- Commit info is missing from your build in CI
In these cases, you can manually tag your release in Runway by going to the Release step, choosing a commit to tag, and clicking Create Tag.
When tagging your production release commit, Runway will attach all artifacts generated from your active production build workflow as assets on your release record.
This automation requires the Provide build artifact downloads automation to be enabled. Artifact downloads are currently only supported via GitHub Actions and Bitrise.
Runway will add appropriate labels and/or fix versions when they are missing from tickets that are associated with the release. These label and fix version patterns are defined in Integration settings > Feature affiliations for the app.
Missing labels or fix versions will be applied to a ticket if a piece of code work is in a given release (exists in that release’s diff) and that piece of code work references that ticket (in commit message, PR title, or former branch name)
The missing labels or fix versions are applied once code work enters the final release diff (i.e. exists on the release branch and is in the diff for the release).
Runway will download all artifacts generated from your CI build workflow, and provide direct download links to them from the Runway interface. Additionally, Runway will include artifact information in Slack build success notifications, including a link to find those downloads in Runway.
Artifact downloads are currently only supported via GitHub Actions and Bitrise.
Runway may create pull requests to fulfill various tasks on demand (for example, bumping your version in code on a development branch). If this automation is enabled, Runway will attempt to merge these PRs without manual approval.
Runway will create a new Runway release record for your next version when your current release is kicked off. This will assign a release pilot and provide a selectable upcoming release via the versions timeline in the App Overview screen.
The roles and permissions granted to users are based on the mapping of Runway roles to App Store Connect roles or Play Console permissions. See below for the default values of this mapping for each platform.
You can configure your own custom mapping rules for each app under App Settings > Team roles.
Users in Runway will automatically be invited to your app in App Store Connect, and assigned the appropriate roles based on their Runway roles.
The App Store Connect API key in use by Runway must have the "Admin" role in order to enable user sync.
Default mapping of Runway role to ASC role:
Runway Role | Default role on App Store Connect |
|---|---|
Admin | Admin |
EM | App Manager |
PM | App Manager |
Engineer | Developer |
Design | Marketing |
Ops | Customer Support |
Marketing | Marketing |
CX | Customer Support |
QA | Customer Support |
Approver | Customer Support |
For additional details on Apple Developer Program roles and associated permissions, see Apple’s documentation.
Users in Runway will automatically be invited to your app in Google Play Console, and be granted the appropriate permissions based on their Runway roles.
You must update the permissions on the service account associated with your Runway Play integration to “Admin” in order to enable user sync. You can do this by visiting API Access > View Play Console permissions > Account permissions and selecting "Admin"
Default mapping of Runway role to permissions on the Play Console:
Runway Role | Play Console Permissions |
|---|---|
Admin | Admin (all permissions) |
EM |
|
PM |
|
Engineer |
|
Design |
|
Ops |
|
Marketing |
|
CX |
|
QA |
|
Approver |
|
For additional details on the Google Play Console’ developer account users and managing permissions, visit their documentation.