Prioritise release jobs ahead of feature builds - #23280
Conversation
Beta builds and the Releases V2 tasks run on the `wordpress-android` pipeline, in the same `android` queue as every PR build, so a release manager waits behind whatever feature work is already queued. `release-builds.yml` was given `priority: 1` at some point; nothing else on the release path was. `beta-builds.yml` takes it per step, matching `release-builds.yml`: two of its steps sit inside a `group`, and Buildkite's schema has no `priority` on a group step while the docs are silent on whether a pipeline-level value reaches steps nested in one. The flat files take it pipeline-wide, so a step added to them later inherits it rather than silently arriving unprioritised. Part of [AINFRA-3040](https://linear.app/a8c/issue/AINFRA-3040); audit in [AINFRA-3032](https://linear.app/a8c/issue/AINFRA-3032). --- Generated with the help of Claude Code, https://claude.com/claude-code Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
🟢 Approval recommended
The changes are limited to adding Buildkite priority: 1 fields and appear consistent with existing release pipeline step-level priority usage.
Pull request overview
This PR updates the Buildkite release-related pipelines so release manager workflows (beta builds, releases, promotions, code freeze tasks, release notes updates) are scheduled ahead of regular feature/PR builds in the shared android agent queue.
Changes:
- Set
priority: 1at the pipeline level for release manager “flat” pipelines so their jobs default to higher scheduling priority. - Set
priority: 1on each step inbeta-builds.yml, including steps nested undergroup, to ensure consistent prioritization. - Keep existing release workflow structure intact while improving queue behavior for time-sensitive release operations.
File summaries
| File | Description |
|---|---|
| .buildkite/update-release-notes.yml | Adds pipeline-level priority so release-notes updates are scheduled ahead of feature builds. |
| .buildkite/publish-release.yml | Adds pipeline-level priority for the publish release workflow. |
| .buildkite/promote-production.yml | Adds pipeline-level priority for production promotion picker workflow. |
| .buildkite/promote-beta.yml | Adds pipeline-level priority for beta promotion picker workflow. |
| .buildkite/new-hotfix-release.yml | Adds pipeline-level priority for creating hotfix releases. |
| .buildkite/new-beta-release.yml | Adds pipeline-level priority for creating beta releases. |
| .buildkite/finalize-release.yml | Adds pipeline-level priority for finalizing releases. |
| .buildkite/finalize-hotfix-release.yml | Adds pipeline-level priority for finalizing hotfix releases. |
| .buildkite/complete-code-freeze.yml | Adds pipeline-level priority for code-freeze completion workflow. |
| .buildkite/code-freeze.yml | Adds pipeline-level priority for starting code freeze workflow. |
| .buildkite/beta-builds.yml | Adds step-level priority to ensure grouped/nested beta build steps also run at higher priority. |
Review details
- Files reviewed: 11/11 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
|
|
| # yaml-language-server: $schema=https://raw.githubusercontent.com/buildkite/pipeline-schema/main/schema.json | ||
| --- | ||
|
|
||
| priority: 1 |
There was a problem hiding this comment.
Actually I don't think priority is a valid top-level attribute in Buildkite pipelines and instead only a job/step attribute. So this is probably not valid
AliSoftware
left a comment
AliSoftware
left a comment
There was a problem hiding this comment.
Ok, nevermind, TIL that this was actually supported.
It was apparently added to the documentation back in Aug 2024, and to the JSON schema back in Dec 2025, and doesn't seem to depend on a buildkite-agent version—as it is instead an attribute managed by the control node (on the buildkite servers' side) assigning jobs to agents—so should be supported transparently regardless of what buildkite-agent version our CI agents are using.
…iority-1-to-release-pipeline
Adds
priority: 1to the beta and release pipelines so release jobs jump the queue ahead of feature builds, and the release train stalls less.Closes AINFRA-3040.
AI-generated details.
Description
Beta builds and the Releases V2 tasks run on the
wordpress-androidpipeline, in the sameandroidqueue as every PR build, so a release manager waits behind queued feature work.release-builds.ymlalready hadpriority: 1; nothing else on the release path did — includingbeta-builds.yml, triggered from the same fastlane path (fastlane/lanes/release.rb:580).The ten flat files take it pipeline-wide so later steps inherit it.
beta-builds.ymltakes it per step, matchingrelease-builds.yml: two of its steps sit inside agroup, and Buildkite does not document whether a pipeline-level value reaches those.Part of AINFRA-3038 (this repo: AINFRA-3040); audit in AINFRA-3032.
Testing instructions
CI here does not exercise these files — the upload step only uploads
pipeline.yml. Locally, all eleven parse and all 16 steps resolve to priority1.Real confirmation is the next release: the beta or code freeze job should show Priority
1in Buildkite, against0for a PR build.