Queue tracker PR builds instead of cancelling them (#902)

The tracker opens its PR and then labels it, so a new tracker PR starts
two build runs at once. The second cancelled the first, whose always-run
`result` job then failed and left a red required check on the PR (#901)
until the surviving run finished. The tracker also force-pushes every two
hours, which would cancel long builds the same way the sync branches did.

Treat auto/track-branches like auto/sync-*: the newer run waits and
reuses the finished build's artifacts.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

.github/workflows/build-pr.yml

@@ -20,16 +20,18 @@ on:
         description: "Space-separated package directories to build"
         required: true
 
-# A new push normally cancels the PR's in-flight build. The sync bots'
-# branches (auto/sync-*) are the exception: they are force-pushed with fresh
-# upstream releases several times a day, which kept cancelling multi-hour
-# aarch64 builds before they could finish. There the newest run waits
-# instead (GitHub keeps at most one pending run per group, replacing older
-# pending ones), and when it starts it reuses every artifact the finished
-# build uploaded, so only packages whose tree changed are built again.
+# A new push normally cancels the PR's in-flight build. The bots' branches
+# (auto/sync-* and auto/track-branches) are the exception: they are
+# force-pushed with fresh upstream releases several times a day, which kept
+# cancelling multi-hour aarch64 builds before they could finish. There the
+# newest run waits instead (GitHub keeps at most one pending run per group,
+# replacing older pending ones), and when it starts it reuses every artifact
+# the finished build uploaded, so only packages whose tree changed are built
+# again. The tracker labels the PR it opens, so a new tracker PR starts two
+# runs at once; cancelling the first left a red `result` on the PR (#901).
 concurrency:
   group: build-${{ github.event.pull_request.number || github.run_id }}
-  cancel-in-progress: ${{ !(github.event.pull_request.head.repo.full_name == github.repository && startsWith(github.head_ref, 'auto/sync-')) }}
+  cancel-in-progress: ${{ !(github.event.pull_request.head.repo.full_name == github.repository && (startsWith(github.head_ref, 'auto/sync-') || github.head_ref == 'auto/track-branches')) }}
 
 jobs:
   # Builds cost real machines, so they run only for trusted authors:

docs/upstream-sources.md

@@ -229,9 +229,9 @@ These packages were already excluded from automatic AUR updates. The migration p
 `sync-upstream.yml` pushes its PR with the built-in `GITHUB_TOKEN`, so GitHub
 holds the PR's build and test runs for approval. The workflow labels its own
 PR `build-approved`, and its `approve` job releases the held runs for each
-commit it pushes. A push to an `auto/sync-*` branch does not cancel the PR's
-build in flight: the new build waits, then reuses every artifact the finished
-one uploaded.
+commit it pushes. A push to an `auto/sync-*` branch, or to the tracker's
+`auto/track-branches`, does not cancel the PR's build in flight: the new
+build waits, then reuses every artifact the finished one uploaded.
 
 Because of that push, GitHub starts no `pull_request_target` workflow for the
 PR, so `auto-merge-pr.yml` never arms it: a maintainer merges it.