-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Networking stress tests moved out of Hosted pool #35011
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
Networking stress tests moved out of Hosted pool #35011
Conversation
Tagging subscribers to this area: @ViktorHofer |
Tagging subscribers to this area: @dotnet/ncl |
/azp list |
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-ssl |
Azure Pipelines successfully started running 1 pipeline(s). |
So the BYOC unix pools don't have powershell in them. I spoke with @alnikola and the most natural thing is to follow what we do for all our build scripts which is providing a Unix and a Windows build scripts to not require devs to install other dependencies in their machines and to have native support. I helped @alnikola by creating the Unix scripts. PTAL cc: @eiriktsarpalis |
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-ssl |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-ssl |
As the matter of fact, that PR can fix only Linux tests. but on NanoServer they fail with actual HttpClient errors detected by stress test application. I see a lot of TaskCanceledExceptions thrown on |
@MattGal I ran commands from http.yml building Linux tests locally on my Windows machine and confirmed that step 6 completes successfully (see below). Since I updated the base SDK image version to .NET 5.0, it now uses
|
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
- Windows OS version set to 1809
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-ssl |
Azure Pipelines successfully started running 1 pipeline(s). |
@MattGal I fixed container builds on both of Windows and Linux for HttpStress and only Windows build for SslStress. On Linux SslStress container build cannot execute This is the last issue preventing me from completing this PR. HttpStress tests are currently failing due to actual errors in the scenario and our team will check and prioritize them accordingly, but I have to complete this PR first. |
I'll take a look and see if I have anything useful to note; do note the running user on these build agents has some options to unblock itself (will ping you on Teams about specifics) |
@alnikola we need to fix the permissions of the added script (chmod +x). I will push that now. I will close the PR and trigger the pipelines manually from a branch to not waste resources (runtime, runtime-live-build, runtime-perf build, etc). |
Test build with chmod +x in the .sh file: https://dev.azure.com/dnceng/public/_build/results?buildId=692516&view=results |
@safern I repeated |
/azp run runtime-libraries stress-http |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-libraries stress-ssl |
Azure Pipelines successfully started running 1 pipeline(s). |
@MattGal @safern Strangely, but after I merged this into master Windows container builds started failing on For the reference, these are pipeline runs I did on this PR right before merging. As you can see, |
I'm looking, but maybe we can hold off declaring "some machines are not properly configured" til this has worked a single time in master after your commit :)? All we know is it was tried once and failed. All this error is telling us is that the thing you invoked wrote to standard error. We get nothing else, and with the way it's being invoked I'm pretty sure that we're not even getting its std err. Example local ISE docker compose std err:
That top line may be missed by console host. Since you log none of the args being passed to the command, so I'd recommend adding logging to what the actual command you're running and all other values we can't see here; a few Write-Outputs can really explain things. My first guess is that PRs have a different value for BUILD_CONFIGURATION than post-CI |
Fixes #34780