Skip to main content

Build priority

Abstract

You can configure build priority on Bitrise: by setting a value between -100 and 100, you can determine the order in which queued builds should run.

By default, builds run in simple chronological order: the build that was triggered first runs first. However, you can configure build priority, allowing you to fast-track critical builds to the top of the queue.

You can assign numerical priorities: a value between -100 and 100. The higher value, the higher the priority of the build. A build with a higher priority is executed sooner than a build with a lower priority. By default, all builds have a priority of 0.

You can set priorities for:

  • Pipelines and Workflows. You can assign a priority to individual Worklows or even Pipelines. Assigning a priority to a Pipeline will assign all its constituent Workflows the same priority

  • Triggers: Each trigger condition can be given a priority.

  • Manual builds: When starting a build on the UI or via the Bitrise API, you can set a priority that determines its position in the queue.

Availability

The build priority feature is only available for Workspaces on Teams, Pro, and Enterprise plans. If you are not on these plans, but interested in the feature, contact us!

Configuring priority when starting a build manually

You can set a priority when starting a build manually. The priority only takes effect if other builds are queued when you start a build.

The priority set when manually starting the build overrides all other priorities.

  1. Open Bitrise CI and select your project.

  2. On the main project page, click Start build.

  3. Select the Advanced option.

    manual-build-priority.png

  4. Find the Priority field and set an integer value between -100 and 100. The default value is 0.

Configuring priority for build triggers

You can set priority for build triggers on the GUI of the Workflow Editor and in your configuration YAML file. Trigger priority overrides Pipeline and Workflow priority.

Workflow Editor

Configuration YAML

  1. Open the Workflow Editor.

  2. Select the Workflow or Pipeline you need.

  3. Go to the Triggers tab.

  4. Create a new trigger or edit an existing one and find the Priority input.

    trigger-priority.png

  5. Set an integer value between -100 and 100: higher number means higher priority. The default value is 0.

  1. Open your configuration YAML file.

  2. Find a trigger in a Pipeline or Workflow.

  3. Add the priority input with an integer value between -100 and 100: higher number means higher priority. The default value is 0.

    workflows:
  primary:
    steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - deploy-to-bitrise-io: {}
    triggers:
      push:
      - branch: main
        priority: 10

Configuring priority for Pipelines and Workflows

You can configure priority by setting a value between -100 and 100 for the Priority property of any given Workflow or Pipeline. The default value is 0.

Pipeline priorities override Workflow priorities. If a pipeline is triggered and assigned a priority, all constituent workflows will be triggered with the same priority.

Configuring Pipeline priority

Workflow Editor

Configuration YAML

  1. Open the Workflow Editor.

  2. On the left, select Pipelines.

  3. Select the Pipeline you need and click Properties.

    pipeline-priority.png

  4. In the Priority input field, provide an integer between -100 and 100. The default value is 0.

  1. Open your Configuration YAML file.

  2. Find the Pipeline you need and add a priority input with an integer value between -100 and 100.

    If you don't have a priority input set, the Pipeline will have a default priority of 0.

    pipelines:
  best-pipeline:
    priority: 10

Configuring Workflow priority

Workflow Editor

Configuration YAML

  1. Open the Workflow Editor.

  2. On the left, select Workflows.

  3. Select the Workflow you need from the dropdown menu and select the Properties tab on the right.

    workflow-priority.png

  4. In the Priority input field, provide an integer between -100 and 100. The default value is 0.

  1. Open your Configuration YAML file.

  2. Find the Workflow you need and add a priority input with an integer value between -100 and 100.

    If you don't have a priority input set, the Workflow will have a default priority of 0.

    workflows:
  best-workflow:
    priority: 10

Order of precedence for priority settings

You can set priority levels for:

  • Pipelines and Workflows.

  • Triggers.

  • Manually triggered builds.

These priorities can conflict. For example, you have a Workflow called test. It has a priority of 10. You also have a trigger configured for this Workflow: it is triggered if code is pushed to the development branch. This trigger has a priority of 15.

In such a scenario, Bitrise determines the build priority by the order of precedence:

  1. Manual overrides: Manually starting a build overrides all other priority settings.

  2. Trigger-specific priority settings: A trigger's priority setting overrides the priority settings of the Pipelines or Workflows it triggers.

  3. Pipeline-level priority settings: The Pipeline's priority overrides the priority settings of its constituents Workflows which are all given the same priority as the Pipeline.

  4. Workflow-level settings: If no other configuration element is given a priority setting, the Workflow priority determines overall build priority.

Example 1. 

Here’s an example snippet that shows how to set priorities at various levels:

  workflows:
    A:
     steps: []
    B:
     steps: []
     priority: 4
     triggers:
       push:
       - branch: release
         priority: 2
       - branch: development


  pipelines:
   P:
    priority: 3
    workflows:
      A: {}
      B: {}

In this example:

  • If Workflow A is run as a standalone build, it has a priority of 0 (the default priority value).

  • If Workflow B is run as a standalone build (for example, if code is pushed to the development branch), it has a priority of 4.

  • If code is pushed to the release branch, Workflow B is triggered with a priority of 2.

  • If Pipeline P is triggered, both A and B Workflows will run with priority 3.


In this section: