A build is a series of jobs, specified by the app’s Workflow which is a collection of Steps. The app’s build configuration is specified in the bitrise.yml configuration file which you can modify in bitrise.io’s graphical Workflow Editor.
When a build is running, these scripts will be downloaded and executed in the order you’ve defined in your Workflow, with the input parameters you set. They will produce the predefined outputs set as Environment Variables.
Triggering builds ⚓
Trigger builds by:
- Clicking the
Buildbutton on the application’s page (manual build trigger).
- Scheduling with a selected branch and frequency.
- Webhooks: automatically trigger a build after each code/tag push or pull request to the given branch.
- Our API.
Read more about triggers in our Triggering builds guide.
The build process ⚓
- Triggering the build.
- Environment preparation: A virtual machine will be provisioned and prepared to run the build. Build specific Environment Variables are preset so you can use these in your Steps. You can find more information about the available stacks in the Workflow Editor, on the Stack tab.
- Workflow execution: Steps in Workflows are executed in the same order as defined in the Workflow Editor of your application, from top to bottom. You can reorder the Steps by dragging them around. The log each Step generates will be displayed on the build’s details page.
- Cleanup: After the execution of the build, a build log is created and stored on the Bitrise server. The virtual machine running the build is destroyed so your code/files will never fall into the wrong hands.
Build status ⚓
On the Builds page, you can track the current status of all your builds. There are six different build statuses:
- Waiting for worker: When a build is triggered, Bitrise creates a virtual machine to run it. If computing resources aren’t immediately available, the build is placed in a queue and the Waiting for worker status is displayed.
- Initializing: The worker assigned to create the virtual machine is processing the build request.
- Running: Once a virtual machine is ready to go, the build starts running. This means that Bitrise is executing all the Steps defined in your Workflow.
- Aborted: A build can be aborted manually by the user, or automatically either by the Rolling builds feature or because your build time has run out.
- Failed: In most cases, a build fails if any of the Steps fails. There are exceptions, such as the caching Steps, and you can mark Steps as skippable which means even if they fail, the build will keep running.
- Success: If Bitrise successfully executes all Steps that aren’t marked as skippable, the build is marked as successful.
You can always check your build status on the Builds page of the app, and you can send status reports to your Git provider.
Build concurrency ⚓
Build concurrency determines how many builds you can run simultaneously. Builds over your subscription plan’s concurrency count will be marked as on hold. They will start whenever your ongoing builds are finished and you have a free build slot.
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.