-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HttpStress and SslStress builds are broken #60769
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsHTTP and SSL stress builds are currently broken on Windows: To run stress tests with the current bits on main, our dockerfiles overwrite the 6.0 runtime preinstalled to the image with the locally built 7.0.0 runtime/eng/docker/libraries-sdk.windows.Dockerfile Lines 17 to 19 in ce4dd5f
This typically works, but now it looks like it is problematic in some cases. Note that for some reason this is only broken on Windows now. To overcome this issue, I tried to install the 7.0 nightly SDK with
I think the best way to overcome this is problem would be to separate building and execution of the stress project. For the former we can use the pre-installed SDK. For the latter we can utilize @ViktorHofer @safern @Anipik any tips or insights that can help us? (Either solving the dll resolution issues or using
|
Linux is broken as well, it just doesn't fail the build since it builds within the docker image: |
dotnet test respects a runsettings file which is automatically generated when a test library is built. That runsettings file hardcodes the path to the dotnet host to use: runtime/eng/testing/.runsettings Line 20 in a7bdb16
$$DOTNETHOSTPATH$$ is replaced with the path to the testhost folder, so it's just an invocation of the dotnet host under the testhost folder.
That's recipe for failure as the assumption that a 6.0 SDK is compatible with a 7.0 testhost or that a 7.0 live built testhost is compatible with a 7.0 SDK in some cases is wrong. Why can't you just use the live built testhost folder to invoke the stress tests?
Why not just follow the same approach as the other libraries tests and use the live built targeting pack to build the tests against and the testhost to run them? |
Because we used the 6.0 SDK to build them which can only target
This is a term I'm unfamiliar with. Is this the thing used to build a project against |
I agree, this would be the ideal approach if we could make it work. I think part of the complication here is that these apps require ASP.NET. Maybe that's no longer a concern? |
I see, I missed that requirement. Until aspnetcore is an optional workload that can be bootstrapped, you probably need to continue using a matching pre-built SDK. |
Perhaps we should consider not using ASP.NET here. We don't use it for functional tests. |
That would probably be easiest. If aspnetcore would be a strict dependency I would probably suggest to use a pre-built SDK that supports aspnetcore but then use live targeting pack so that you can compile against the live built net7.0 assemblies. For running, if you would build the apps as self-contained, you could consume the live built runtime pack and would remove the dependency on the SDK entirely. |
It is a strict dependency. Getting rid of aspnet would mean implementing and maintaining a test server that covers all stress cases, or to move the test server logic to a separate project and containerize it separately. Both seem to be overly expensive options to me.
I think this is the direction we need to go, but I could use some guidance or at least some starting points on using pre-built SDK to build against local, live built dll-s. HttpStress is a standalone project today, not integrated with the dotnet/runtime infra. |
https://github.com/dotnet/runtime/blob/main/eng/targetingpacks.targets is everything that you need. That file needs to be imported and the required properties that need to be set are documented in it as well. You would set these to:
|
HTTP and SSL stress builds are currently broken on Windows:
https://dev.azure.com/dnceng/public/_build/results?buildId=1434301&view=logs&j=2d2b3007-3c5c-5840-9bb0-2b1ea49925f3&t=8ca65746-3bfa-57bf-9141-d805b5d39db5
https://dev.azure.com/dnceng/public/_build/results?buildId=1434299&view=logs&j=2d2b3007-3c5c-5840-9bb0-2b1ea49925f3&t=ac0b0b0f-051f-52f7-8fb3-a7e384b0dde9
To run stress tests with the current bits on main, our dockerfiles overwrite the 6.0 runtime preinstalled to the image with the locally built 7.0.0
testhost
runtime:runtime/eng/docker/libraries-sdk.windows.Dockerfile
Lines 17 to 19 in ce4dd5f
This typically works, but now it looks like it is problematic in some cases. Note that for some reason this is only broken on Windows now.
To overcome this issue, I tried to install the 7.0 nightly SDK with
dotnet-install.ps1
and replace the 7.0 runtime bits with the locally built ones as recommended by @ManickaP in her #60364 (comment), but unfortunately that leads to another build-time dll resolution error:I think the best way to overcome this is problem would be to separate building and execution of the stress project. For the former we can use the pre-installed SDK. For the latter we can utilize
testhost
the same way we do in normal functional tests, however I'm not an expert on SDK internals, so I don't know how to achieve the separation, the waydotnet test
works in the runtime repo is a black box to me.@ViktorHofer @safern @Anipik any tips or insights that can help us? (Either solving the dll resolution issues or using
testhost
runtime for executing the stress tests without touching the installed SDK.)The text was updated successfully, but these errors were encountered: