-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Closed
Labels
Description
Context
Today we have BuildCopConnectorLogger.cs as a connector between Logging infrastructure and BuildInfrastructure. It Implements the MSBuild ILogger interface and hance can be plugged in as logger, receive the BuildEventArgs data and push those to the BuildCopManager.cs.
The MSBuild is able to read the binlog and replay it to any attached loggers (via MSBuild.exe <binlogpath> <other args - to attach loggers etc>).
Goal
We aim to leverage both facts in 'BuildCop post-build mode' - MSBuild will replay BuildEventArgs from binlog and send them to BuildCop that will report it's findings.
Subproblems
(Order is not strict)
- Author an end-to-end unit test that would create binlog, then replay it in BuildCop mode and assert that report is outputed
- Identify and fix or plan fix for any issues with analysis during replay mode
- Make sure .editorconfig files (touched by BuildCop, or possibly all) in the source tree that is build with binlogger attached (
/bl) are embedded into binlog file.
- In replay mode - use .editorconfig files from the binlog (if any).
- The build might have happen on top of sources without .editorconfig files, while in replay mode we might want to tune the rules - so add an option to specify editorconfig file during replay (e.g. via command line switch)
- (skip now) There will be Analyzers, that will need to hook directly into executing nodes (the way of distinguishing those is yet TBD) - those will need to be skipped during replay analysis mode, but some message/warning will need to be output to inform about this. In a future version we might as well reconstruct some of those 'execution-specific' data during replay mode (e.g. we can reconstruct
ProjectInstance/Projectfrom the data embedded in binlog)