-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Remove closed issues from issues.targets #75363
Conversation
Tagging subscribers to this area: @hoyosjs Issue Detailsnull
|
/azp run runtime-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
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.
Nice, thanks for cleaning this up!
@eduardo-vp The failed mono tests hit an interesting corner case - you correctly removed the exclusions marked with the issue #41519 but apparently the issue was just closed due to being a duplicate of another issue, #64127, that is still pending. I think that in this particular case we probably need to put the exclusions back and just rename the tracking issue link. Hopefully there are no more cases like this. |
Duplicate issues should be resolved as "not planned" instead of "completed" and we should recognize the former as "not fixed". |
@AntonLapounov - thanks for the comment, I've also been thinking that we should somehow clarify the workflow here. The interesting question is, how would it work in this particular case? OK, let's assume that @radical closed the issue #41519 as "not planned" and so Eduardo didn't try to remove the exclusions from the issues.targets file. Now what should happen once #64127 is fixed? The exclusions would stay in issues.targets forever unless someone took additional action to somehow subsequently change the status of #41519 to "completed" as a consequence of completing #64127. In general I think that we'd need better tracking of the issue graph on GitHub to be able to fully automate this. |
/cc @dotnet/runtime-infrastructure as this PR uncovers a larger question of properly tracking GitHub issue dependencies. |
I think we want to maintain invariant that the issue the test is disabled against is active. Thus the closure of an issue with |
/azp run runtime-coreclr outerloop |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
… be fixed either
…ate/issues.targets
/azp run runtime-coreclr outerloop |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr outerloop |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr outerloop |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr outerloop |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
This reverts commit 105841c.
Note: another failure from this change was #76845, which only appears during JitStress runs (on Linux/arm32). |
No description provided.