-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log TaskStarted line and column #6399
Conversation
We currently log the file in which a task is invoked, but we don't log the line and column, so if there are multiple tasks of the same name in a target, there's an ambiguity as to which task it is. Pass the line and column information to TaskStartedEventArgs. Fortunately we don't need to increment the binlog file format as we can piggy-back on the existing infrastructure for messages which can already log line and column if present. Reading older binlogs with the new MSBuild will work as the line and column flags won't be set, so no attempt to read anything extra. Reader newer binlogs with old MSBuild (same version but pre-this change) will also work as the line and column fields will be set and the existing infrastructure will read them, but nothing will consume that data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused about your older binlog/newer MSBuild comment. If it tries to read something that isn't there, then even if accessing the line/column variables doesn't throw an error, why isn't the reader off of where it should be?
LineNumber = reader.Read7BitEncodedInt(); | ||
ColumnNumber = reader.Read7BitEncodedInt(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like @Forgind I also wonder if the change is backward compatible. Shouldn't you be testing for BuildEventArgsFieldFlags.LineNumber
and BuildEventArgsFieldFlags.ColumnNumber
here before reading the integers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I understand. This code is separate from the binlog logic and has no versioning concerns, is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is unrelated to binlog and used by the node packet translator to send events from worker nodes to central node. Nodes will only talk to each other if they’re the same MSBuild version.
LineNumber = reader.Read7BitEncodedInt(); | ||
ColumnNumber = reader.Read7BitEncodedInt(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I understand. This code is separate from the binlog logic and has no versioning concerns, is that correct?
We currently log the file in which a task is invoked, but we don't log the line and column, so if there are multiple tasks of the same name in a target, there's an ambiguity as to which task it is.
Pass the line and column information to TaskStartedEventArgs.
Fortunately we don't need to increment the binlog file format as we can piggy-back on the existing infrastructure for messages which can already log line and column if present. Reading older binlogs with the new MSBuild will work as the line and column flags won't be set, so no attempt to read anything extra. Reader newer binlogs with old MSBuild (same version but pre-this change) will also work as the line and column fields will be set and the existing infrastructure will read them, but nothing will consume that data.