Triggering builds with pull requests

You can set up a trigger so that every time a pull request is opened from a specified source branch to a specified target branch of your repository, a build is automatically triggered on Bitrise.

Webhooks for triggering builds

Triggering builds automatically requires an incoming webhook set up with the hosting service of your repository. Read more in the Webhooks section.

By default, every new app you add has a trigger that triggers a build every time any pull request is opened in your repository.

Open your app on bitrise.io.
Open the Workflow Editor.
Select the Triggers tab.
Select the PULL REQUEST option.
In the existing trigger, click the SOURCE BRANCH and TARGET BRANCH options.

If you have your own trigger set up already, click the + ADD TRIGGER option to set up a new one.
Type the names of the source branch and the target branch. Make sure there are no spelling errors, otherwise the trigger won’t work.

You can leave either the source or target branch fields, or both, empty: the trigger will work accordingly. For example, if you leave both empty, as is the default with new apps, every pull request will trigger a build.
Select the workflow you wish to trigger (for example, primary).
Click Save in the top right corner.

Using patterns when specifying a branch or tag

The * symbol can be used in your configured triggers as a wildcard in branch or tag names. It can also be used in patterns. For example, the pattern *-dev can be used for any branches or tags with the suffix -dev. Please note that when there are multiple triggers, only the first matching trigger will start a workflow.

And you’re done! From now on, if a pull request is opened in your repository, Bitrise will trigger a build with the selected workflow!

You can trigger and abort builds with the Bitrise API. Define parameters for the build: for example, branch, tag or git commit to use. Custom environment variables can be defined...

Both incoming and outgoing webhooks can be set up with the Bitrise API. They are important for automatic build triggering and the reporting of build events to other services.

You can schedule your builds to run automatically at a specific time of the week so that you can check your logs when it's most convenient for you.

Environment Variables (Env Vars) consist of a key and a value, as well as optional attributes. They can be defined on the level of apps, Workflows or Steps.