Repository navigation
Remove StaticTokenCredential, let Azure SDK handle token refresh - #1879
Merged
Merged
Conversation
Previously, AzureTokenCredentialProvider would immediately fetch a token and wrap it in a StaticTokenCredential that returned the same token forever. This caused issues with long-running builds (>1 hour) where the token would expire before it was actually used. Now the provider returns the underlying AzurePipelinesCredential (or DefaultAzureCredential in DEBUG) directly, allowing the Azure SDK to handle token caching and automatic refresh when tokens are close to expiring. Also removes the commented-out 'prepopulate credential cache' code from BuildCommand and PublishManifestCommand since it's no longer needed.
mthalman
approved these changes
Dec 8, 2025
8 tasks done
lbussell
added a commit
that referenced
this pull request
Jan 12, 2026
During release staging, authentication to the staging storage account was failing. This is because of the changes to token caching from #1879. Previously we needed to pass the token scope as an argument to the `GetCredential()` method, since that method would create both the credential and the token in order to cache the token up front. But the scope is only needed to create the token. Since we no longer cache the token, we need to pass in the scope to the credential's `GetToken` method instead. The scope argument to `GetCredential()` is not used. This is a targeted fix to unblock release staging. A follow-up PR will contain a proper refactor to remove the unused argument from `TokenCredentialProvider.GetCredential`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, AzureTokenCredentialProvider would use
WorkloadIdentityCredentialduring builds. In order to work around Workload Identity Credential lifetimes, we implemented a StaticTokenCredential that immediately fetched the requested token and cached it forever (added with #1321). WIF token lifetimes are documented here.Since #1712, we use
AzurePipelinesCredentialinstead.AzurePipelinesCredentialhandles all of the lifetime/expiration concerns. We can use it directly and allow the Azure SDK to handle caching and automatic refresh when tokens are close to expiring. I have not found any documented restrictions on its lifetime. The System.AccessToken and the resulting AzurePipelinesCredential should be valid for the entire length of the pipeline job and no longer.I have built a test version of ImageBuilder with this change and validated it against our longest running build job, here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2854918&view=logs&j=5b10b89b-008d-5f76-ef8b-7fc595d90c00&t=a505c4d8-3f6e-56eb-f81a-e4be2494dd9a
It happily spends over 3 hours building images and then has no trouble pushing them.