CI build of Linux runtime doesn't stop on coreclr compilation errors

[janvorli]

I have noticed that when a native coreclr stuff compilation failed, the build was continuing, tried to run corerun that was not produced and failed. Then it tried to generate packages for coreclr and failed again. But it still continued building further stuff, finally failing when trying to crossgen something else.

We should fail the build as soon as coreclr build failed.

Here is an example, see lines 3129 and on:
https://dev.azure.com/dnceng/public/_build/results?buildId=587189&view=logs&j=da3b6fae-2b9c-515e-f961-941b19f305e4&t=e211c71e-116d-5222-99f8-68e08c58ca66

[janvorli]

cc: @jkoritzinsky, @trylek

[janvorli]

cc: @ViktorHofer - I can see it repros locally on Linux as well if I just run the root build script and have some error in one of the coreclr native cpp sources. I haven't spotted this before as I use just the src/coreclr/build.sh script in my workflow.
It seems the failure exit codes from the .sh scripts invoked by Exec command in the src/coreclr/runtime.proj are not detected / propagated for some reason.

[janvorli]

In my local testing, I can see this logged to the console, similar to the CI job:
/home/janvorli/git/runtime/src/coreclr/runtime.proj(26,5): error MSB3073: The command ""/home/janvorli/git/runtime/src/coreclr/build-runtime.sh" -x64 -debug -os Linux" exited with code 2.
But the build keeps going on.

[janvorli]

Hmm, it seems that the crossgen-build.proj doesn't have any dependency on the runtime.proj - how are the dependencies specified then?

[hoyosjs]

They are specified as separate projects to build here

runtime/eng/Subsets.props

Line 182 in b8c9296

<ProjectToBuild Include="@(CoreClrNativeCoreLibProjectToBuild)" />

And they get run in arcade here: https://github.com/dotnet/arcade/blob/011efe624f0cfed1f218cc9893864e2d712c8845/src/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj#L249

crossgen-corelib.proj is marked to be built serially, so it builds after the other defined projects. I do agree the experience here isn't great to not stop of failure. However, I think StopOnFailure gets ignored sadly.

[davidwrighton]

Fixed by #42104. This was a simple issue of capturing the exit code at the wrong point.