-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Bump Helix workitem timeout for libraries outerloop runs #49876
Bump Helix workitem timeout for libraries outerloop runs #49876
Conversation
Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer Issue DetailsSystem.IO.Compression.Brotli.Tests takes 870 seconds already which is quite close to the 900s timeout. This caused the timeout seen in https://helix.dot.net/api/2019-06-17/jobs/4f8db33f-41d8-43c4-97b9-a65dfd229437/workitems/System.IO.Compression.Brotli.Tests/console
|
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
eca8036
to
0868a90
Compare
System.IO.Compression.Brotli.Tests takes 870 seconds already which is quite close to the 900s timeout.
0868a90
to
e3e8f84
Compare
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
cc @jeffhandley @adamsitnik @carlossanlop @jozkee Any idea why the Brotli tests take that long on Outerloop? |
I think the reason is that in PR builds we run with the Debug config while on rolling builds it uses Release (which takes about 230sec) |
My concern was more an overall question about if Brotli tests are intended to take that long unrelated to the configuration used. |
Can we move forward with this? The timeout bump is needed right now and the failed tests in this PR are already known/tracked by #44352. |
The Brotli tests predate me, could you please tell me how I can check the execution times of given tests using our infra? Once I have at least a single troublemaking test name I can take a look |
ARM seems 2x-3x slower than x64. |
@wfurt I think that's a bit misleading since from what I can see we run different build configs in main vs. PR outerloop runs. E.g. if you just look at PR outerloop runs then all of the System.IO.Compression.Brotli.Tests runs that took longer than 12mins in the last 10 days were on amd64:
@adamsitnik unfortunately we don't track data about passing tests in Kusto, only in AzDO (and they're not quite easy to extract from there) |
@akoeplinger are you still interested in this change? |
@ericstj Yeah I still think this is a good idea since the outerloop runs tend to take longer by design. |
OK, what are next steps here? My original comment was due to the PR age. Do you just need reviewers to approve? |
@ericstj yeah, just need someone to approve. |
@adamsitnik does the data that @akoeplinger provided help? |
This is good to go in but our policy says that before merging the CI build should be recent so let me retrigger CI. |
/azp run runtime-libraries-coreclr outerloop |
/azp run runtime |
/azp run dotnet-linker-tests |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-dev-innerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-staging |
Azure Pipelines successfully started running 1 pipeline(s). |
System.IO.Compression.Brotli.Tests in debug configuration (which we use in PR builds) takes 870 seconds already which is quite close to the existing 900s timeout.
This caused the timeout seen in https://helix.dot.net/api/2019-06-17/jobs/4f8db33f-41d8-43c4-97b9-a65dfd229437/workitems/System.IO.Compression.Brotli.Tests/console