Build Distro buckets

Buckets are groups of builds that can be automatically shared with a group of bucket members that you define. Buckets are a great way to group together similar kinds of builds (think release candidate builds, development/alpha builds, or even feature team builds) so there’s no ambiguity about the kinds of builds that are available for testing in a given bucket.

All apps will come with two default buckets: the Release Candidate bucket, and the Development bucket. Certain users will also have Personal buckets created by default.

Bucket settings

Buckets have properties that can be configured to refine the kinds of builds that are available in a bucket and who has access to them. The following properties can be configured on any build bucket:

  • Name: the display name of the bucket.

  • Rules: the rules that define how builds get pulled into the bucket.

    • PR rule: Build artifacts will be automatically pulled into the bucket from matching workflow runs on any pull requests that are open against the configured base branch.

    • Branch rule: Build artifacts will be automatically pulled into the bucket from matching workflow runs on the configured branch.

  • Filename(s): the names of the files (including file extension) that Runway should automatically pull from your workflow's build artifacts. If left blank, all files with the .ipa extension will be pulled in for iOS and tvOS platforms, and all files with the .apk extension will be pulled in for Android platforms

  • Org-wide access: enable org-wide access to make your bucket available to all users in your Runway org. Anyone in your Runway org with access can view and install builds from the bucket. If this setting is disabled, only bucket members can view and install builds from the bucket.

  • Public access links: enable the public access link to make your bucket available to users external to Runway. Users with the link will be able to view, download, and install builds from your bucket without logging in or being members of Runway.

Configuring bucket rules

Configuring PR rules

When a PR rule is configured, build artifacts will be automatically pulled into the bucket from matching workflow runs on any pull requests that are open against the configured base branch. To configure a PR bucket rule, you'll define the following:

  • CI/CD workflow and base branch: the CI/CD workflow and PR base branch where Runway should pull build artifacts from. You can optionally specify workflow arguments if needed.

    • Branch fields support tokenized branch patterns, including the wildcard token {*} and several more token types.

  • (optional) User: Filter CI/CD workflow runs by PR author – only builds triggered by PRs authored by one of the specified users will be pulled into the bucket. Note that connecting a Version Control integration is required for this configuration.

  • (optional) Filename(s): The file names of the artifact files that be surfaced for each build. By default, all .ipa files will be surfaced for Apple platforms, and all .apk files will be surfaced for Android platforms. Tokenized patterns and wildcards are supported here as well.

Configuring branch rules

When a branch rule is configured, build artifacts will be automatically pulled into the bucket from matching workflow runs on the configured branch. To configure a branch rule, you'll define the following:

  • CI/CD workflow and branch: the CI/CD workflow and branch where Runway should pull build artifacts from. You can optionally specify workflow arguments if needed.

    • Branch fields support tokenized branch patterns, including the wildcard token {*} and several more token types.

  • (optional) User: Filter CI/CD workflow runs by commit author – only builds triggered by commits authored by one of the specified users will be pulled into the bucket. Note that connecting a Version Control integration is required for this configuration.

  • (optional) Filename(s): The file names of the artifact files that be surfaced for each build. By default, all .ipa files will be surfaced for Apple platforms, and all .apk files will be surfaced for Android platforms. Tokenized patterns and wildcards are supported here as well.

Artifact files from Github Actions are stored in zip files. Use the "File name(s)" field to enter an artifact file name with the relevant extension (.ipa , .apk, or .aab ); Runway will extract the file if it exists.

When org-wide access is enabled, any non-members with access to the bucket will be treated as users with the Tester bucket permission.

Uploading builds to buckets

There are currently three ways to upload builds to a bucket:

  • Configure a bucket rule and Runway will automatically pull build artifacts from matching workflow runs into the bucket

  • Upload builds manually to the bucket using the build upload flow on the bucket details page. You can upload .ipa files to buckets on apps of iOS platforms, and .apk or .aab files to buckets on apps of Android platforms

  • Upload builds programmatically to a bucket using Runway's public API

Default buckets

Runway will by default start your team off with three distinct buckets: Release Candidates, Development, and for certain user groups, a Personal Bucket.

Release Candidates bucket

The Release Candidates bucket can be used to group together release candidate builds – if your team is already set up on Runway's Release Management product, the Release Candidates bucket will be automatically configured with a branch rule that uses your app’s Release Candidate CI/CD workflow and release branch (as defined during the setup flow of your CI/CD integration).

Release Candidate buckets will by default include all org admins as well as all default user groups as bucket members. Org admins will be included as bucket admins. Default user groups will be included as bucket testers.

Development bucket

The Development bucket can be used to group together development or alpha builds – if your team is already set up on Runway's Release Management product, the Development bucket is by default configured with a branch rule that uses your app’s Development CI/CD workflow and working branch (as defined during the set up flow of your CI/CD integration).

Development buckets will by default include all org admins as well as default user groups as bucket members. Org admins will be included as bucket admins. Default groups will be included as bucket testers.

Personal bucket

Any user with an admin role in the org, or any user in the app with a PM, EM, or Engineer role will get a Personal bucket by default. These buckets are designed as freeform workspaces – a bucket where you can upload any kind of build to share with whomever you like.

Personal buckets aren't configured with a bucket rule by default, and don’t include any members besides the owner of the bucket.

Automations

Bucket automations are scoped to the bucket they are a part of. To see a list of available bucket automations, visit the Build Distro bucket automations page.

Notifications

The notifications tab in the bucket details shows a list of available notifications for the given bucket. Notifications can be toggled on and off at the individual bucket level, and customized so that notifications for a given bucket can be sent to different channels of your choosing.

Bucket notifications are enabled by default on the Release Candidate and Development default buckets.

You can also opt into receiving email notifications for each bucket-level notification type. For more details visit the email notification settings documentation.

Bucket permissions

See below for details on which bucket actions can be performed by which kind of bucket member.

Action
Admin
Uploader
Tester

Update

Yes

No

No

Update notifications

Yes

No

No

Update members

Yes

No

No

Share builds with individual testers

Yes

No

No

Upload builds

Yes

Yes

No

Update build tester notes

Yes

Yes

Yes

Install builds

Yes

Yes

Yes

Edit buckets

Yes (except personal)

No

No

Delete buckets

Yes (except personal)

No

No

Last updated

Was this helpful?