[Built-in analyzer] The same file is written by multiple tasks during the build #9881
Closed
Assignees
Labels
Area: BuildCheck
Priority:1
Work that is critical for the release, but we could probably ship without
triaged
Comments
13 tasks
|
It would be nice if this further analyzed across projects for cases where the build invoked those projects in parallel. |
|
The plan is for this to work across projects but if you mean building in VS, then yes, we will likely have to do extra work to make build analyzers work across projects when the build is orchestrated by VS. |
anangaur
added
the
Priority:1
ladipro
added a commit
that referenced
this issue
May 13, 2024
Contributes to #9881 ### Context Some build checks will want to analyze tasks executed during build. This PR is adding support for these by introducing several new types and implementing processing of task-related logger events in `BuildEventsProcessor`. ### Changes Made - Added `RegisterTaskInvocationAction` for analyzers to call to subscribe to task events. - Added `TaskInvocationAnalysisData` as a unit of reporting task events to analyzers. - Implemented a transform from `TaskStartedEventArgs`, `TaskFinishedEventArgs`, and `TaskParameterEventArgs` to `TaskInvocationAnalysisData`. ### Testing New unit tests.
ladipro
added a commit
that referenced
this issue
May 23, 2024
Contributes to #9881 ### Context When `TaskParameterEventArgs` represents an output parameter of a task, it currently does not capture the name of the parameter. This information is generally useful as multiple output parameters can be assigned to the same item, and it's important for the BuildCheck infrastructure to provide a consistent object model to build analyzers. Additionally, output parameters that are assigned to properties are currently logged as textual log messages `Output Property: {0}={1}` which miss the name of the parameter as well. ### Changes Made Added two new properties on the `TaskParameterEventArgs` class, including the requisite serialization support. Updated logging to populate the properties with the name of the task parameter and the name of the build property, respectively, and updated BuildCheck infra to expose it to analyzers subscribed to task parameter events. All task parameters are now logged as the structured `TaskParameterEventArgs` and the kind of parameter (input, output to property, output to item) can be determined by examining the args. ### Testing - Tweaked existing unit test and updated the relevant BuildCheck test. - Verified that when using the standard console logger, the resulting textual log is identical. - Verified that binlog viewer without the corresponding changes displays the forward-compat warning about unknown data. ### Notes - Complementary binlog viewer PR: KirillOsenkov/MSBuildStructuredLog#780 - The change is behind a changewave because it is technically a breaking change for third party loggers. Co-authored-by: Rainer Sigwald <[email protected]>
ladipro
added a commit
that referenced
this issue
Jun 10, 2024
Fixes #9881 ### Context We believe there is value in flagging cases where the same file is written by more than one task during a build. dotnet/source-build#4390 is an example of a recent hard-to-diagnose build issue that could have been prevented by this analyzer. ### Changes Made This PR adds a new built-in analyzer and makes a few supporting changes. ### Testing - Existing and new unit tests. - Built a few larger repos with the analyzer enabled. ### Notes The changes contain a fix/workaround for #10176.
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
This issue tracks one of the BuildCheck analyzers we would like to ship in-box with MSBuild.
Goal
Implement an analyzer with the following rule: Each file written to disk during the build should be written only once. Also known as "double writes" analysis.
Notes
Writing the same file multiple times often leads to file access issues and non-deterministic builds. This analyzer will report the violation if it happens within one project as well as between multiple projects. It can be implemented by checking the parameters of well-known tasks like
CopyandCsc(see the implementation in binlog viewer). Alternatively, it can be implemented based on target outputs, as used by the engine for up-to-date checks.The text was updated successfully, but these errors were encountered: