Update CoreFxOptimizationData, ProjectNTfs, ProjectNTfsTestILC to master-20190207.3, beta-27407-00, beta-27407-00, respectively (master) #35142
Conversation
|
Discarded CI Status: 10:hourglass: 1:heavy_check_mark: (click to expand)
|
dotnet-maestro-bot
force-pushed
the
master-UpdateDependencies
branch
from
237c4ce to
b8dce5c
Compare
|
Discarded CI Status: 1:x: 10:heavy_check_mark: (click to expand)
|
dotnet-maestro-bot
force-pushed
the
master-UpdateDependencies
branch
from
b8dce5c to
a38a6ec
Compare
|
@ViktorHofer, we're continuing to see tons of CI failures for UWP legs due to: Is someone investigating? Should we disable the UWP legs in the meantime? |
|
I opened https://github.com/dotnet/core-eng/issues/4956 a while ago which could help. Looking at the MC infra logs I noticed that the error only occurs on the following machine: a00115F. @MattGal Could that single machine have a different configuration than the others or somehow be in a bad state? @stephentoub I understand the frustration here but disabling the leg will definitely regress UWP in master. Who is going to fix the failing tests afterwards? A perfect example is uapaot in master right now. We have 1.3k failing tests because we disabled the leg in official builds / CI a year ago because of some failures. I hope that with upgrading our machines to RS5 the issue won't reoccur. |
The leg is failing on most PRs, which means we're effectively already ignoring it. Such regressions are going to happen regardless of whether the leg is disabled or not, but with it enabled yet basically always failing, it's slowing down productivity. |
Me and others (i.e. #35004) are working hard on getting it to a sane state. Disabling it would be counter-productive. As said, I understand that the current situation is imperfect and impacts other verticals productivity. What I ask for is a little more time so that we can see if upgrading to RS5 helps and/or if the one machine I pointed out is indeed corrupted. |
|
Updated the core-eng link above which pointed to the wrong issue. |
I very much appreciate that. Thanks.
I don't see how; if a leg is always red, developers stop looking at the failures. Developers working to drive down the failure rate can opt-in to the leg. If it's going to be addressed soon (e.g. this week), great, leave it enabled. Otherwise, I think it should be disabled. cc: @danmosemsft |
|
Ok the machine I pointed out is not the only one failing. @maryamariyan just pointed me to logs where another one is failing (a0010QH): https://mc.dot.net/#/user/maryamariyan/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Fmaster~2F/test~2Ffunctional~2Fcli~2F/5582680dfd393b92ded3ee127afc1cc297625821/workItem/System.Composition.Convention.Tests/wilogs At least we have a certain degree of consistency. If a test submission fails, it fails consistently (3 times because of the retry mechanism). Also if multiple test submissions fail, it's likely that they ran on the same machine. @safern @MattGal is it possible to randomize the machine assignment during the retry mechanism? |
+1. IMHO, default legs that are consistently failing for more than a day should be disabled without questions asked. If they are left failing, it tends to start broken window syndrome and more failures to sneak through unnoticed.
As I have said in the offline conversation, UWP state in master is lower priority at this point. The priority at this point is .NET Core 3.0 features and bugs. |
|
Discarded CI Status: 1:x: 9:heavy_check_mark: (click to expand)
|
1 similar comment
|
Discarded CI Status: 1:x: 9:heavy_check_mark: (click to expand)
|
dotnet-maestro-bot
force-pushed
the
master-UpdateDependencies
branch
from
a38a6ec to
c9eb24d
Compare
dotnet-maestro-bot
changed the title
…ter-20190207.3, beta-27407-00, beta-27407-00, respectively
dotnet-maestro-bot
force-pushed
the
master-UpdateDependencies
branch
from
c9eb24d to
ae5401a
Compare
…ter-20190207.3, beta-27407-00, beta-27407-00, respectively (dotnet/corefx#35142) Commit migrated from dotnet/corefx@719e29d
/cc @dotnet/maestro-reviewers-core