Fix recurring TSA onboarding failure in release builds - #41167
Merged
Ben Hillis (benhillis) merged 1 commit intoJul 24, 2026
Conversation
The 1ES Official governed template (v2/Microsoft.Official.yml) force-runs the TSA onboard/upload step even though globalSdl.tsa.enabled was false. With no tsaoptions.json, TSA auto-derives the codebase name 'microsoft_Microsoft.WSL_microsoft/WSL', which contains the illegal characters '.' and '/'. Onboarding therefore fails with PreconditionFailed and 'Guardian exited with an error exit code: 1' on every release build. Add .config/tsaoptions.json with an explicit, sanitized codebase name and wire the release pipeline's globalSdl.tsa to consume it via configFile. Bugs are routed to the WSL area path in the OS project. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: aa582972-8aa3-43c9-9fe3-6a9ff2bc1ab2
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes deterministic TSA onboarding failures in the release OneBranch pipeline by providing an explicit TSA codebase configuration (with a sanitized codebase name) and wiring the release pipeline to consume it.
Changes:
- Enable
globalSdl.tsain the release pipeline and point it at a repo-checked-in TSA options file. - Add
.config/tsaoptions.jsondefining the TSAcodebaseNameand routing metadata so onboarding/upload doesnât rely on auto-derived (invalid) names.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
.pipelines/wsl-build-release-onebranch.yml |
Enables TSA for official release builds and supplies configFile so onboarding uses an explicit codebase config. |
.config/tsaoptions.json |
Adds the TSA options needed to avoid invalid auto-derived codebase names and route TSA results correctly. |
Blue (OneBlue)
approved these changes
Jul 24, 2026
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.
Problem
Every release build (which extends the 1ES Official governed template
v2/Microsoft.Official.yml@templates) fails the SDL compliance leg with:The Official template force-runs the TSA onboard/upload step even though
globalSdl.tsa.enabledwasfalse(that flag only suppresses bug-filing, not onboarding). With notsaoptions.json, TSA auto-derives the codebase namemicrosoft_Microsoft.WSL_microsoft/WSL, which contains the illegal characters.(fromMicrosoft.WSL) and/(from themicrosoft/WSLrepo slug). Onboarding therefore fails deterministically and breaks/degrades every release build.Fix
.config/tsaoptions.jsonwith an explicit, sanitizedcodebaseName(microsoft_WSL) and TSA routing (OS project, WSL area path).globalSdl.tsaat it viaconfigFileand setenabled: trueso the config is consumed.Nightly and PR pipelines extend
v2/Microsoft.NonOfficial.ymlwhich does not force TSA onboarding, so they are left unchanged.