Increase jitstress job run frequency #49020
Conversation
Change dotnet#41856 reduced stress job frequency to once per day, alternating between main and the release branches. However, the release branches get few changes yet still run the job. (Also, all the release branches run the job at the same time.) Change to running the job daily in main, where most development happens. Also change the runs to daily in the release branches, but change to only run if the branch has changed since the last run.
|
Tagging subscribers to this area: @hoyosjs Issue DetailsChange #41856 reduced stress job frequency to once per day, alternating Change to running the job daily in main, where most development
|
|
Not really, perhaps @ilyas1974 might have more info? |
|
What type of information are you looking for with regards to Windows ARM64 queues? |
|
@hoyosjs This change should only increase the amount of testing when changes are done in the release branches. So, once per day if a release branch has changes, the pipeline will run in both that release branch and in 'main', whereas before it would only run in one or the other. (Actually, not precisely one: the way it was written, on the days the release branch was scheduled, all release branches would run, concurrently. Even if there were no changes.) So, I think the general concern with any change in scheduling is: do we have machines to handle the load? And I think @hoyosjs question is specifically: do we have win-arm64 machines. Another question: presumably if we merge this, do we need to port it back to the 6.0 preview branches to stop them from running on the old schedule? |
|
We have about 100 ARM64 systems running windows in the windows.10.arm64v8.open queue. |
|
Mostly checking to see if https://dev.azure.com/dnceng/public/_build?definitionId=658&_a=summary and https://dev.azure.com/dnceng/public/_build?definitionId=833&_a=summary would have any issues with being run daily (basically, run daily jobs against arm64 windows helix queues). I just took some time to look at it. They send around what a CI build would send to the queue (6 jobs, with the regular amount of work items). this should be fine. |
Yes, and 5.0 |
|
Looks like 5.0 doesn't run these (or any) jobs: it's only configured to run for changes in |
ghost
locked as resolved and limited conversation to collaborators
Change #41856 reduced stress job frequency to once per day, alternating
between main and the release branches. However, the release branches
get few changes yet still run the job. (Also, all the release branches
run the job at the same time.)
Change to running the job daily in main, where most development
happens. Also change the runs to daily in the release branches, but
change to only run if the branch has changed since the last run.