ci(uidrift): clone wandb/core's default branch instead of master

[wandbjake]

Description

Prep for renaming wandb/core's default branch master -> main (done later in an announced cutover). This change works before and after the rename.

• uidrift-scan.yml: git clone --single-branch without --branch master clones core's remote HEAD and sets refs/remotes/origin/HEAD (verified with a local single-branch clone); the log line now reads origin/HEAD.
• scripts/uidrift/config.py: SOURCE.default_head origin/master -> origin/HEAD; comments/tests updated to match.

The raw Weave OpenAPI URL in sync_openapi_spec.py (raw.githubusercontent.com/wandb/core/master/...) is left alone here: it already has a fallback, and it is tracked as a post-cutover item in the core rename runbook.

Testing

• uidrift unit tests
• pre-commit on changed files

Link to Devin session: https://coreweave.devinenterprise.com/sessions/e8431f366b364b3c8855620e1c58f823
Open in Devin Desktop: https://coreweave.devinenterprise.com/desktop/session/e8431f366b364b3c8855620e1c58f823?variant=devin
Requested by: @wandbjake

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
wandb	🟢 Ready	View Preview	Sep 29, 2026, 2:43 PM

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'Devin'.

• Disable automatic comment, CI, and merge conflict monitoring

---

Original prompt from Devin Bot

Repo: wandb/core (plus small PRs in wandb/wandbot-3000 and wandb/infra-services). Goal: prepare wandb/core to rename its default branch master -> main (the wandb org default). The rename itself will be done later by a repo admin in an announced cutover. Do NOT rename the branch, change repo settings, apply terraform, or edit external systems (Ctrlplane, Datadog, Currents UIs). Deliver PRs plus a cutover runbook.

Principle: every change must work BEFORE and AFTER the rename. Prefer keying off the default branch (github.event.repository.default_branch, origin/HEAD, ~DEFAULT_BRANCH, git symbolic-ref refs/remotes/origin/HEAD). Where that isn't possible, accept both names ([master, main], (master OR main), dual image tags). Do not touch wandb/weave or wandb/sweeps.

Attached is my audit report (master-to-main.md). The core section lists the known breakpoints. Treat it as a starting point and re-grep for anything missed.

PHASE 1: cross-repo dependents on core@master (land first; each is its own PR in its repo):

• wandb/wandbot-3000:
  • terraform/main.tf has ${uri}/flake_report/currents/core/master. Find the route handler and make it accept main too; configure it to follow the default branch or both.
  • Workflow-failure filters/tests match head_branch: "master" for core workflow runs (src/filters, src/tasks/github-workflow-failures). Make them accept core's default branch or both names.
  • Datadog metric tags branch:master are data, so leave them.
  • Note: another session is separately handling wandbot-3000's OWN default-branch rename (sync-notify-labels workflow, summary-comment link). Don't touch those files, to avoid conflicts.
• wandb/infra-services (minecart):
  • minecart/apps/api/src/routes/system.ts:~243 hardcodes const branch = "master". Resolve it from the repo's default_branch via the GitHub App client, or accept both.
  • minecart/apps/web/src/pages/EnvironmentDeploymentDetailsPage.tsx:~415 filter preset `version.metadata... (5191 chars truncated...)

[devin-ai-integration]

👀 1 finding needs your review

Devin reviewed the finding on 47278ce and left it for you. Click a finding below to jump to its comment.

For your review (1)

• Local drift scans miss renamed branch

View all findings in Devin Review

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🟡 Local drift scans miss renamed branch

After core's branch rename, default_head can still select master in an existing checkout. origin/HEAD is a local symbolic ref that ordinary fetches do not retarget. Local scans then miss commits on main, or fail if master is pruned.

Learn more

A fresh CI clone sets origin/HEAD from the remote default. Existing local checkouts keep their own symbolic origin/HEAD, which a normal fetch does not retarget when the server renames its default branch. scan uses that symbolic ref to select the entire commit range; ownership also reads through it. If the old remote-tracking branch remains, local scans silently keep reporting against it; if it is removed, the scan cannot resolve its head.

Example: A local checkout has origin/HEAD -> origin/master. Core renames master to main and the user fetches origin/main. Running the default scan still selects origin/master, instead of the commits on origin/main.

Recommended fix: Resolve the source remote's advertised HEAD before selecting a default head in an existing checkout, or refresh origin/HEAD with git remote set-head origin -a after fetching the new branch. Ensure the default also handles checkouts where origin/HEAD was never initialized.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

This gap is real, but it only affects existing local clones of wandb/core after the rename, and this PR didn't introduce it. The old origin/master default breaks the same way once master is renamed away. CI isn't affected: uidrift-scan.yml makes a fresh --single-branch clone on every run, so origin/HEAD points at the current default branch. The core cutover runbook tells engineers to run git remote set-head origin -a, which fixes local clones. I left the code alone because refreshing origin/HEAD inside the scanner would add a network call to local runs. If a maintainer wants that, it can go in a follow-up PR.