Run outerloop pipeline only for release branches, not staging/preview #114971
Conversation
I noticed we were sending 30k workitems each day to various Helix queues, this is due to the outerloop pipeline having a schedule triggere which matches old preview branches or the staging branches. This fixes that and also sets it so that the trigger only applies if there are actual source changes.
There was a problem hiding this comment.
Pull Request Overview
This PR modifies the outerloop pipeline schedules to ensure that only release branches trigger the pipeline and that it runs only when there are source changes.
- Updated the branch filter in eng/pipelines/libraries/outerloop.yml from using a wildcard pattern to "release/*.0" to narrow the branches triggering the run.
- Added "always: false" to both outerloop.yml and outerloop-mono.yml to run the pipelines only if there are changes since the last scheduled run.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| eng/pipelines/libraries/outerloop.yml | Modified branch filter pattern and enabled condition-based scheduling. |
| eng/pipelines/libraries/outerloop-mono.yml | Enabled condition-based scheduling to run only on source changes. |
Comments suppressed due to low confidence (1)
eng/pipelines/libraries/outerloop.yml:9
- Please verify that the new branch pattern 'release/*.0' correctly captures all intended release branches, as it may exclude branches that do not strictly end with '.0'.
+ - release/*.0
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
| include: | ||
| - main | ||
| - release/*.* | ||
| - release/*.0 |
There was a problem hiding this comment.
The -staging variants might be more useful as they get active changes. Granted - neither release branch gets a lot of scrutiny.
There was a problem hiding this comment.
yeah I don't have a strong opinion. My thinking was that since they don't get a lot of scrutiny anyway (they've been red forever) it'd be better to save more reasources by only running on the .0 branches which change less often.
There was a problem hiding this comment.
I assume the always change is really the more important of the two here.
There was a problem hiding this comment.
If we ever decide to once again release a version like 3.1, this filter won't apply. Shouldn't it just be release/*?
There was a problem hiding this comment.
@carlossanlop no since that one will match the preview/staging branches again. if we ever go back to .1 then lots of other stuff will break, this is the least of my concerns :)
There was a problem hiding this comment.
This is definitely an improvement over queueing every release branch every night. If there are concerns about missing things we could keep the old pattern and just change always.
Adding @jeffschwMSFT for thoughts
|
Do we need to backport? |
Yes since AzDO takes the schedule trigger from the branch, not main |
|
/ba-g failures are unrelated and can't be caused by the .yml schedule changes |
|
/backport to release/10.0-preview4 |
|
Started backporting to release/10.0-preview4: https://github.com/dotnet/runtime/actions/runs/14649316331 |
|
/backport to release/9.0-staging |
|
/backport to release/8.0-staging |
|
Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/14649323195 |
|
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/14649324329 |
I noticed we were sending 30k workitems each day to various Helix queues at the same time, causing a heavy load on the system. This is due to the outerloop pipeline having a schedule trigger which matches old preview branches or the staging branches.
This fixes that and also sets it so that the trigger only applies if there are actual source changes.