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.
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
Users/haiz/add verbosity for target circular dependence #5711
Users/haiz/add verbosity for target circular dependence #5711
Changes from 6 commits
436c472
197263e
5742b01
0961dc0
eb91aa5
28d28dc
87302fa
a21241d
8323608
791ba89
6335f9c
0981570
ead5b85
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Would it make sense to log the parent graph of these, too? Maybe log what it currently logs at normal verbosity and log the parents at diagnostic verbosity?
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 did some investigation here. I think it is hard to get the parent graph here.
Here are my reasons:
_requestEntry.RequestConfiguration.ActivelyBuildingTargets
to store the targets are being executed. If the current target is in this dictionary, which means we can't find the circular by checking the currentparentTargetEntry
._requestEntry.RequestConfiguration.ActivelyBuildingTargets
, this also means we have lost the previous parent information to add it to_requestEntry.RequestConfiguration.ActivelyBuildingTargets
.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 not sure I understand the reason you gave to not use parentTargetEntry. You're saying that we already would have checked for a cycle via parentTargetEntry, so if it gets here, that way to figure out the cycle won't work? Or are you saying the parentTargetEntry is often null?
If there is no way to get the parent information, then I think this is good.
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 mean "we already would have checked for a cycle via parentTargetEntry, so if it gets here, that way to figure out the cycle won't work". So I think currently we have no way to get the parent information.
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.
The reason it's better to have this sort of thing in strings (and having two separate but almost identical error messages) is that there, it gets translated into a variety of different languages. If we leave it here, everyone worldwide would see it in English.
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.
+1, as much of the error message should exist within the resource as possible. Though I see the reason it is in its current state.
I propose we have two resources here with the same error code: ``` and
CircularDependencyInTargetGraph
. Same error code, different message where `CircularDependencyInTargetGraph` has most of the message listed here with many more required arguments. And `CircularDependency` remains the same.Of course, the
ThrowInvalidProject
calls that pass null will no longer need to pass null, so long as they revert to theCircularDependency
resource.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.
@Forgind , I agree with @benvillalobos 's proposal. I once did this in previous commits. Do you have any concerns?
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.
Yeah, that's fine. I was pushing for two separate error messages in strings, but although it wasn't clear, I'm fine with them sharing an error code in this case.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.