Migrate dn-bot-devdiv-drop-rw-code-rw PAT to WIF service connection

[missymessa]

Summary

Replaces the \dn-bot-devdiv-drop-rw-code-rw\ PAT with a WIF-based service connection (\dnceng-devdiv-drop-rw-code-rw-wif) for DevDiv drop access.

Changes

• Add AzureCLI@2 task in the Publish job to acquire an Entra token via the WIF service connection before the MicroBuildVstsDrop task
• *Set _DevDivDropAccessToken* at runtime using the WIF-acquired token instead of the static PAT from \DotNet-VSTS-Infra-Access\ variable group
• Remove static PAT variable reference from the variable declarations

Context

This is part of the PAT-to-Entra migration tracked by AB#10146. The WIF service connection \dnceng-devdiv-drop-rw-code-rw-wif\ (backed by app registration \dnceng-devdiv-drop-rw-code-rw-wif, App ID: \7106a410-fbcb-4750-a202-879077f925ec) was previously created and verified. The same pattern was successfully deployed in dotnet/fsharp#19598.

Validation

Note: PR validation pipelines read YAML from \main, not the PR branch. The actual WIF migration will be validated on the first post-merge CI build.

[Copilot]

Pull request overview

This PR migrates DevDiv drop publishing in the official Azure Pipelines build from a static PAT (dn-bot-devdiv-drop-rw-code-rw) to a WIF-based service connection, acquiring an Entra ID access token at runtime before the VSTS drop upload task.

Changes:

• Replaced the _DevDivDropAccessToken variable’s static PAT value with an empty placeholder to be populated at runtime.
• Added an AzureCLI@2 step in the Publish job to acquire an Azure DevOps access token via the dnceng-devdiv-drop-rw-code-rw-wif service connection.
• Continued passing _DevDivDropAccessToken into 1ES.MicroBuildVstsDrop@1 for drop upload, now sourced from the WIF-acquired token.

[nohwnd]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[missymessa]

Thanks for looking at this @nohwnd! The pipeline trigger exclusion is expected — the PR validation YAML on the main branch excludes paths or the PR source branch isn't covered by the trigger config.

Important: Even if PR validation runs, it will execute the old YAML from main (not the PR branch), so it won't actually validate the WIF change. The real validation happens post-merge on the first CI build from main.

Context on why this is safe:

• The WIF service connection (dnceng-devdiv-drop-rw-code-rw-wif) has been validated in roslyn (builds green since May 22), fsharp, test-templates, and interactive-window — all use the same SC and the same 1ES.MicroBuildVstsDrop@1 task pattern.
• The SC is already authorized for the vstest pipeline (def 1222).
• The only change is swapping $(dn-bot-devdiv-drop-rw-code-rw) (PAT from variable group) for the WIF-based $(_DevDivDropAccessToken) sourced from an AzureCLI@2 task.

If you'd like a manual test build before merge, I can queue one from the dnceng/internal side with the source branch override. Otherwise, merging and monitoring the first post-merge build is the standard approach we've used for the other repos.