You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It feels like is a correctness issue in the build, which is causing IbcMerge to run multiple times concurrently on the same dll. Once we determine the root cause, it would be good to add some kind of speedbump to prevent such breaks from making it in in the future.
For example, maybe there is a change to our correctness checks we could make to detect the bad condition. Alternatively, maybe we could gate certain categories of changes on someone manually running the official build first. For example, there's a bot which complains when you modify public API--a bot might also complain when the structure of the build is modified in certain ways and ask an MSFT contributor to run an official build prior to merging.
This is all assuming it was a change on our side that broke things, which I don't think we are fully certain of yet.
Actually it might be good to fix this in arcade - currently the ApplyOptimizations target runs after CoreCompile even when the CoreCompile target itself is skipped (because outputs are up to date wrt inputs). That seems unnecessary and leads to these errors. The fact that we CoreCompile MS.CA.dll in our builds multiple times might be expected - the second time happens inside ResolveProjectReferences and is skipped which seems fine.
In fact, some arcade targets related to ApplyOptimizations have Inputs/Outputs that cause them to be skipped if they were already performed:
Before closing this issue, please remove the workaround from code where this issue is linked.
The text was updated successfully, but these errors were encountered: