consider running all pipelines on eng/ updates

[wfurt]

I understand this is tradeoff but the infrastructure changes are not as frequent and they seems to have higher risk of breaking some less common pipelines. There are at least two examples:

1. our stress and enterprise test scenario pipelines are getting broken on regular cadence as they do not run on most changes
2. updates to test matrix - update alpine test images #81841 was green and then eventually fixed by Revert "update alpine test images" #82309. In this case, coreclr tests use library tests, but they do not run test changes.

Since the PR pipelines runs are selective based on the modified files, it is really difficult to make sure clan CI when updating test images or doing infra changes. We may certainly also do only for subset e.g. eng/pipelines/

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I understand this is tradeoff but the infrastructure changes are not as frequent and they seems to have higher risk of breaking some less common pipelines. There are at least two examples:

1. our stress and enterprise test scenario pipelines are getting broken on regular cadence as they do not run on most changes
2. updates to test matrix - update alpine test images #81841 was green and then eventually fixed by Revert "update alpine test images" #82309. In this case, coreclr tests use library tests, but they do not run test changes.

Since the PR pipelines runs are selective based on the modified files, it is really difficult to make sure clan CI when updating test images or doing infra changes. We may certainly also do only for subset e.g. eng/pipelines/

Author:	wfurt
Assignees:	-
Labels:	area-Infrastructure
Milestone:	-

[ManickaP]

If I were able to trigger ALL pipeline with one azp run command, that would be very helpful, as I could make sure we're not breaking anyone with changes like I did recently. Also trigger like this should prevent any heuristic to skip some legs.

[jkotas]

There are MANY (more than thousand) pipelines defined in the repo. I do not think you ever want to trigger all of them by a single command.

[wfurt]

It would be nice to at least get list easily. We can of course just live with the outcome e.g. fix things as they break and are reported by random people. It is just unpleasant.

[trylek]

I think that at some point "/azp run" without parameters worked like this but dnceng people had to disable it because in accordance with JanK's comment it just flooded the lab with tons of work. While I understand the rationale, I'm afraid that in today budget-tight times it would be very problematic for multiple reasons:

• Especially with re-triggering runs upon each commit on a PR branch, an eng/ PR could stall the lab literally for days.
• There's no easy way to assess whether a particular change has broken all the pipelines as technically many pipelines (apart from the basic ones like PR / CI / outerloop) are not completely green all the time, it generally requires an expert on the particular pipeline (@BruceForstall in about half of the cases) to assess whether a particular change has broken a given pipeline or not.
• @wfurt - /azp list can be used to list those pipelines that can be run via /azp run. Please note it's a manually curated list (IIRC it's actually a flag on the yml file), not the entire set of pipelines supported in the runtime repo.

Thanks

Tomas

[BruceForstall]

Echoing what @jkotas and @trylek said: there are MANY pipelines and some of them are very expensive.

Broad-effect changes should be thoughtful about manually triggering an appropriate set of relevant pipelines for testing. But I don't think that set should be large, and probably shouldn't be automated.

[wfurt]

it seems like nobody is in favor so far. closing.