We know how it feels when a critical build gets stuck in a long queue.
Picture this: you're rushing out a hotfix that can’t wait, or a security patch needs to be deployed quietly but urgently. With limited concurrent build capacity, queued builds are inevitable. If you only have a few builds waiting in the queue, that’s manageable. But on a busy day, that queue can grow long—sometimes even hundreds of builds. In such cases, you’re faced with a tough choice: either wait patiently for your hotfix to get its turn or manually cancel the queued builds, which not only risks knocking out other important work but also means you have to retrigger every single build afterward. Neither option is ideal, and that’s precisely why having a better way to prioritize builds makes all the difference.
That’s why we’ve introduced Build Priority, which is designed to help you keep your critical builds moving ahead of the rest.
Build Priority
With Build Priority, you can now “fast-track” important builds to the front of the queue, ensuring they get executed first. It lets you control the order of your builds by assigning a numerical value between –100 and 100 (0 is the default). You can set priority for pipelines, workflows, triggers, or overrides at the Build Start process. When you hit concurrency limits, builds with higher priority (those with a higher numerical value) run first.
How it works
You can easily integrate Build Priority into your workflow:
- Set a priority directly in your Workflow or Pipeline configuration.
- Assign a priority when configuring Triggers, ensuring the right builds start in the right order.
- Override the default priority at build start, using the UI or our API – perfect for those unexpected situations.
How to think about assigning priority
Every team operates differently—what works perfectly for one might not fit another’s unique workflow. These examples are meant to serve as friendly guidelines to help you find the best balance for your team. Take what resonates with your team's rhythm and tweak the settings as needed—it's all about finding the right fit for you and your projects.
🔥 Critical hotfix pipelines
This is probably the most obvious use case for assigning priority to a build. Imagine your iOS or Android app suddenly starts crashing in production. You need to act fast. By elevating your hotfix build to a higher priority (for instance, setting its build priority to 100, which is the maximum), you can skip the routine jobs and fast track it for execution. This way, you can quickly deploy the fix and reduce user impact. It’s a lifesaver when every minute counts.
📱 Release candidate
App Store or Play Store releases are especially time-sensitive because they require extensive cross-functional coordination, from marketing and support to app store approvals. Prioritizing these builds helps keep all those moving parts in sync. You might prioritize your production release pipeline at a moderately high level, like 60 to 80. An elevated priority helps get your production build through quickly even when many daily development builds are queued, ensuring that your scheduled app update lands on the Play Store on time.
📦 Feedback on feature builds
You want a reasonably quick validation for every commit or merge into your main branch—whether iOS or Android. A dedicated smoke test pipeline with a priority of around 20 could run all the essential tests on simulators or emulators. It checks for basic functionality, unit tests, or UI responsiveness. This way, it still has a higher priority level than the default one but allows room for critical, time-sensitive builds to be prioritized above it.
🔍 Regression testing or dependency updates
Mobile apps often require extensive regression tests and UI automation suites that run across multiple devices or configurations. These pipelines, though important, can be scheduled with a default (0) or lower priority (for example, 10). While they’re vital for long-term quality, they don’t impact immediate releases. So, assigning a lower priority means that when you’re under heavy load, your critical hotfixes and release builds take precedence without completely disabling your comprehensive testing process.
Another typical CI use case in mobile development is handling automated dependency updates. These updates can trigger builds whenever a dependency version changes, ensuring your project stays up-to-date. While these builds are essential, they usually don't need to run as urgently as others. For instance, if a build is triggering on a commit updating a library version, you might assign it a default (0) or just above default priority (for example, 10), ensuring that it runs after more critical builds have been completed.
🧪 Experimental feature branch builds
When your team is experimenting with new features—say, trying out a new iOS framework or an Android UI redesign—you might want these builds to run in the background. Set these pipelines with a lower priority (e.g., 0 or even a negative value, if configured that way) so they don’t interfere with your critical production workflows. This lets your team innovate without worrying about affecting the timely delivery of your core app updates.
Why use Build Priority?
With the right build priorities in place, your CI/CD process becomes more than just a queue—it becomes an engine for timely, reliable releases. Having a well-planned priority setup means that users have to worry less about what others are doing because they are free to pile on more work and trust the system to execute it in the right order. Overall, it reduces the need for supervision, build aborts, approvals etc. Explore these strategies, tweak them for your team, and experience the difference of a prioritized pipeline.
This feature is beneficial for teams managing multiple projects that often run into concurrency limits. If you’re on our Teams, Pro, or Enterprise plans, Build Priority will streamline your process, making your critical work less likely to get held up.
Ready to try it out? Check out the docs here.
Happy building!
