Increase jitstress job run frequency

[BruceForstall]

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.

[ghost]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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.

Author:	BruceForstall
Assignees:	-
Labels:	area-Infrastructure-coreclr
Milestone:	-

[trylek]

LGTM, thank you!

[hoyosjs]

By now we should only have release changes like a week a month. I know for x64 based systems we have the elasticity, but @trylek do you have any context on arm64 windows queues?

[trylek]

Not really, perhaps @ilyas1974 might have more info?

[ilyas1974]

What type of information are you looking for with regards to Windows ARM64 queues?

[BruceForstall]

@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?

[ilyas1974]

We have about 100 ARM64 systems running windows in the windows.10.arm64v8.open queue.

[hoyosjs]

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.

[hoyosjs]

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?

Yes, and 5.0

[BruceForstall]

Looks like 5.0 doesn't run these (or any) jobs: it's only configured to run for changes in master (still).