Use live-built corehost on s390x for creating testhost #58952
Conversation
This allows consuming the dotnet host that was just built instead of relying on a downloaded one. We need to move the `host` subset build before the `libs` subset so that the artifacts are available before externals.csproj runs.
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsThis allows consuming the dotnet host that was just built instead of relying on a downloaded one.
|
|
@ViktorHofer let me know if this makes sense, especially the subsets move. |
|
cc: @agocke |
|
Nice! I thought it is not possible to use live host due to some bindings with SDK (e.g. host changes API that goes hand-in-hand with the SDK), which is why we wait for the whole update cycle: runtime->sdk->{installer,arcade}->runtime. |
My understanding is that the main reason for the current setup is so you don't need to have the native toolchain/compilers to build the corehost if you just want to work on the managed libraries and run tests. |
|
The current issue is more with how we split up our CI pipeline. Right now we build the hosts after the libraries because the host tests require the libraries tests (and because that's how it worked before repo consolidation). |
|
What Jeremy said makes sense but it's also what Alex says. Currently libraries devs are able to just build the libs subset. When building the live host that wouldn't be possible anymore with the current loosely defined dependency. We would want to establish a dependency from the libs test execution to the host. |
|
Please let me know if there's anything missing here or if you don't agree with this approach :) |
ghost
locked as resolved and limited conversation to collaborators
4 participants
This allows consuming the dotnet host that was just built instead of relying on a downloaded one (which doesn't exist for s390x).
We need to move the
hostsubset build before thelibssubset so that the artifacts are available before externals.csproj runs.