[guillaume-dequenne]

Build-number allocation can fail with GitHub HTTP 403 on a pull-request merge commit even when the workflow token has Contents: write. SonarSource/sonar-cpp#7091 reproduces this twice; its Edge authentication and ITs never run because allocation fails first.

Anchor the allocator's lock, number and run-marker refs to the repository's existing default-branch HEAD, resolved once before acquiring the lock. These commits are bookkeeping targets only: the protocol uses the ref names/existence, not commit contents. Existing-marker reuse avoids the extra lookup; lookup failures stop before any refs are written. Locking, number uniqueness, migration and cleanup behavior are retained.

Validation:

• 21 ShellSpec build-number examples pass, including rejection of the PR merge SHA, default-head allocation for all three ref types, lookup failures before writes, and marker reuse without a HEAD lookup.
• Shell syntax and git diff --check pass.
• Shared-action CI passes: full ShellSpec suite, Build Number workflow, pre-commit and the other triggered workflow checks are all green.
• Live ref probe in temporary diagnostic PR #7200 uses the same workflow token for all targets. Production merge SHAs return 403; current production and master heads return 201. Every successful probe ref was deleted (204). The older federation revision also returns 403, separating this blocker from the Edge credential mechanism.
• Live allocator validation passed while this PR's synthetic merge SHA independently returned 403 in the preceding probe. The fixed action successfully claimed build number 113451 against default-branch HEAD, and a second call reused its existing run marker. No extra workflow-write permission was needed.

The production Edge cold-download validation is already green in SonarSource/sonar-cpp#7198. This fix addresses its separate CI allocator blocker. SonarSource/sonar-cpp#7091 now pins this exact commit for its regular/release allocation calls and has full CI running; its merge depends on review of this shared fix. Inclusion in the v2 action line will also fix other existing consumers.

[hashicorp-vault-sonar-prod]

BUILD-12998

[bwalsh434]

@guillaume-dequenne I'll merge this shortly, but FYI the earliest this will go out as a release + push to v2 branch will be tomorrow afternoon CET, potentially the following day, since we're working out some last compatibility issues with another PR that has been pushed to master and will go out in this release.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk · Anchoring build-number refs to default-branch HEAD adds a lookup; lookup failures stop new claims before refs are written, potentially blocking allocation.

Anchors build-number allocator lock, number, and run-marker refs to the repository's default-branch HEAD, resolved once before locking, so allocation no longer fails with HTTP 403 on pull-request merge commits. No issues found.

Verification Rules 2/2 met Repos 9 inspected

Functional validation No results

Rules 2 passed 1 not applicable

✅ Internal artifact registries
✅ Repository license compliance

Broader impact Repos 9 inspected

Cross-repo 9 repositories inspected 0 open impacts

SonarSource/sonar-scanner-cargo Inspected
SonarSource/reddeer Inspected
SonarSource/orchestrator Inspected
SonarSource/git-files-blame Inspected
SonarSource/sonar-packaging-maven-plugin Inspected

4 more repositories

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}