Build Distro buckets
Last updated
Last updated
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.
In addition to the default buckets, custom buckets can also be created. Try creating a bucket for your WIP feature or for your team.
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.
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.
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.
When configuring bucket rules, selected CI/CD workflows must already be configured to generate the required build artifacts (.ipa or .apk files). To read more about how to configure your CI/CD workflow to generate build artifacts and make them available for download, go here.
When org-wide access is enabled, any non-members with access to the bucket will be treated as users with the Tester bucket permission.
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 to a bucket using Runway's public API
Runway will by default start your team off with three distinct buckets: Release Candidates, Development, and for certain user groups, a Personal 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.
Release Candidate buckets will start out with Org-wide access enabled. You can disable this setting from the bucket's settings.
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.
Development buckets will start out with Org-wide access enabled. You can disable this setting from the bucket's settings.
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.
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.
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.
See below for details on which bucket actions can be performed by which kind of bucket member.
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
Update
