Add documentation for enabling binlog collection via env var #12805
+158
−0
Conversation
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
Document the process for enabling binary logging in CI/CD pipelines using environment variables, including supported arguments, argument processing order, and implementation flow.
baronfel
reviewed
Nov 21, 2025
jaredpar
reviewed
Nov 26, 2025
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds documentation for a proposed feature that would enable binary logging in CI/CD pipelines through the MSBUILD_LOGGING_ARGS environment variable. The feature is designed to work even when -noAutoResponse blocks response files, providing an alternative mechanism for enabling diagnostic logging.
Key changes:
- Documents the
MSBUILD_LOGGING_ARGSenvironment variable and its purpose - Specifies supported arguments (
-bland-check) and argument processing order - Describes parameter merging behavior and implementation flow
JanProvaznik
added a commit
that referenced
this pull request
Dec 5, 2025
### Context Docs-only PRs fail the Code Coverage CI job because tests are skipped (no coverage artifacts generated), but the job unconditionally attempts to download and publish those artifacts. ### Changes Made Modified `.vsts-dotnet-ci.yml` CodeCoverage job to respect the `onlyDocChanged` flag: - Added dependency on `IfOnlyDocumentionChanged` job to access the flag - Added `onlyDocChanged` variable to job variables - Conditioned all artifact downloads on `eq(variables.onlyDocChanged, 0)` - Conditioned coverage processing and publishing on `eq(variables.onlyDocChanged, 0)` This aligns with how other jobs (BootstrapMSBuildOnFullFrameworkWindows, CoreBootstrappedOnLinux, etc.) already handle docs-only PRs. ### Testing Pipeline configuration change - will be validated on next PR run. When `onlyDocChanged = 1`, all coverage tasks skip; when `onlyDocChanged = 0`, coverage runs normally. ### Notes Pre-existing typos in job/variable names (`Documention`, `Varibale`) intentionally preserved for consistency across the pipeline. <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>docs only PRs fail code coverage CI check</issue_title> > <issue_description>#12805 > #12857 > > ``` > Code Coverage failed > [3 errors / 0 warnings](https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1217301) > > Annotations > [Check failure on line 9 in Build log](https://github.com/dotnet/msbuild/pull/12857/files#annotation_42398343450) > > @azure-pipelines > azure-pipelines > / msbuild-pr (Code Coverage) > Build log #L9 > > Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\artifacts\CoverageResults\merged.coverage > [Check failure on line 11 in Build log](https://github.com/dotnet/msbuild/pull/12857/files#annotation_42398343487) > > @azure-pipelines > azure-pipelines > / msbuild-pr (Code Coverage) > Build log #L11 > > Artifact LinuxCoreCoverage was not found for build 1217301. > [Check failure on line 9 in Build log](https://github.com/dotnet/msbuild/pull/12857/files#annotation_42398343497) > > @azure-pipelines > azure-pipelines > / msbuild-pr (Code Coverage) > Build log #L9 > > Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\artifacts\CoverageResults\merged.cobertura.xml > ``` > > This is probably because testing is skipped on docs only PRs, in that case code coverage should also be skipped</issue_description> > > <agent_instructions>fix this issue, note that the CI pipeline definition is called .vsts-dotnet-ci.yml</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> - Fixes #12878 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/msbuild/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: JanProvaznik <[email protected]>
|
|
||
| ## Warning Messages | ||
|
|
||
| Issues are logged as **warnings**. Note that users with `/warnaserror` enabled will see these as errors-by opting into this environment variable, users also opt into these diagnostics. |
Member
There was a problem hiding this comment.
Want to make sure we get buy-in on this policy, since the goal is "company-wide opt in" using this feature, and the entity setting the env var may not be the team that owns the codebase.
Member
There was a problem hiding this comment.
@benwitmanmsft here's the proposal for the env-var-based opt-in for binlog analysis. Can you please review at your earliest convenience so we can get going on it?
Member
Author
There was a problem hiding this comment.
added one more configuration MSBUILD_LOGGING_ARGS_LEVEL
|
|
||
| ## Warning Messages | ||
|
|
||
| Issues are logged as **warnings**. Note that users with `/warnaserror` enabled will see these as errors-by opting into this environment variable, users also opt into these diagnostics. |
Contributor
There was a problem hiding this comment.
we may want some other env var to make these not even warnings to make this non-fatal for warnaserror builds. I like the default being warnings for sure, but if there is some env-var way of demoting them out of warning that will make it a lot safer - rather cause binlogs to not be captured than accidentally brick a bunch of pipelines
Member
Author
There was a problem hiding this comment.
good idea, added proposal for MSBUILD_LOGGING_ARGS_LEVEL
benwitmanmsft
approved these changes
Jan 7, 2026
|
|
||
| **Important for company-wide deployment:** When enabling this feature organization-wide (e.g., via CI/CD pipeline configuration), the team setting the environment variable may not be the team that owns individual codebases. Ensure stakeholders understand that builds with `/warnaserror` may be affected. | ||
|
|
||
| **Problem scenarios addressed:** |
Contributor
There was a problem hiding this comment.
why isn't setting MSBUILDDEBUGENGINE + MSBUILDDEBUGPATH sufficient today?
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.
Document the process for enabling binary logging in CI/CD pipelines using environment variables, including supported arguments, argument processing order, and implementation flow.
Fixes #12804