Remove BuildX64 target #41040
Remove BuildX64 target #41040
Conversation
ghost
added
the
|
I'm not sure the file locking is the fault of the Build64 target. It's probably more likely that it's the unlucky victim that just happens to be common with all the failures. I'm suspicious that an IIS functional test is deploying the InProcessWebSite while another functional test is still building. What would be the best way to confirm that? I'm struggling to find what's running in parallel with failing ResolveProjectReferences calls using timeline view in MSBuild Structured Log Viewer. Edit: I was able to find the failed tasks in the tracing view. There doesn't look to be any other parallel tasks. |
|
The runs linked in the description are all about file copy problems in general i.e., #32219. What pointed you toward these two projects instead of the projects mentioned in those errors❔
Without these targets, we're unable to test the standalone deployment option at all. I didn't look at the CI failures in this PR but suspect they failed for that reason.
Odd because our build tends to do a bunch of work in every |
If you look at the binlogs of all three failures that I linked to from just yesterday, all of the failures happened inside the BuildX64 target of InProcessWebSite. I know we've had a bunch of file locking issues on the CI from my own PRs and previous build ops rotations, but I find it very suspicious that all the file locking issues I looked at yesterday happened to be while running InProcessWebSite's BuildX64 target.
Only the Microsoft.AspNetCore.ConcurrencyLimiter.Tests Helix tests failed on macOS which cannot be related to the InProcessWebSite changes.
I meant to write the three linked failures don't have any other parallel tasks in common but forget to finish my sentence. Two of the failures had LinkabilityChecker's ILLink target running in parallel, but not the third. |
halter73
requested review from
Tratcher,
BrennanConroy and
JamesNK
as code owners
| BeforeTargets="Build" | ||
| Condition=" '$(RuntimeIdentifier)' != 'win-x64' AND '$(TargetArchitecture)' != 'arm' "> | ||
| <MSBuild Projects="$(MSBuildProjectFullPath)" | ||
| Properties="RuntimeIdentifier=win-x64;ReferenceTestTasks=false" |
There was a problem hiding this comment.
Suggest adding BuildProjectReferences=false to these Properties instead of removing the whole target. Same in the other project
There was a problem hiding this comment.
Why is this target necessary at all given that all the tests are passing?
There was a problem hiding this comment.
You're right, these two <Target/>s are now redundant and cause problems.
Took a bit to find the change that made these <Target/>s unnecessary. They were mandatory back when I did #39998 because the Publish target was only run in the Helix build step and that step uses -noBuild. Publish fails if the project hasn't yet been built (in this case, for the $(RuntimeIdentifier) of interest).
This changed when I did #40379 because the CopyAssets target in FunctionalTest.props now runs in the prior build step, without -noBuild.
| BeforeTargets="Build" | ||
| Condition=" '$(RuntimeIdentifier)' != 'win-x64' AND '$(TargetArchitecture)' != 'arm' "> | ||
| <MSBuild Projects="$(MSBuildProjectFullPath)" | ||
| Properties="RuntimeIdentifier=win-x64;ReferenceTestTasks=false" |
There was a problem hiding this comment.
You're right, these two <Target/>s are now redundant and cause problems.
Took a bit to find the change that made these <Target/>s unnecessary. They were mandatory back when I did #39998 because the Publish target was only run in the Helix build step and that step uses -noBuild. Publish fails if the project hasn't yet been built (in this case, for the $(RuntimeIdentifier) of interest).
This changed when I did #40379 because the CopyAssets target in FunctionalTest.props now runs in the prior build step, without -noBuild.
amcasey
added
area-networking
I'm opening this draft PR to see how removing the BuildX64 target in InProcessWebSite added in #39998 causes
dotnet publish --no-buildto fail when running tests on the CI. During dev ops I saw a lot of file copy failures and the deleted call to<MSBuild Projects="$(MSBuildProjectFullPath)" Properties="RuntimeIdentifier=win-x64;ReferenceTestTasks=false" Targets="Build" />seems to be to blame.#32219 We've had a bunch of things cause issues with file locks on the CI, but this seems especially frequent during my build ops rotation.