@jaredpar PTAL

Also, why do we run CI on doc changes?

Also, why do we run CI on doc changes?

Several of our CI legs are marked as required. GitHub interprets this as the legs must pass for the PR to be mergable, not that the legs can't fail. Hence if you disable CI on docs changes the legs don't run and GitHub does not consider the PR to be mergable.

Yes this comment deserves a sad face so here you go 😦

Several of our CI legs are marked as required. GitHub interprets this as the legs must pass for the PR to be mergable, not that the legs can't fail. Hence if you disable CI on docs changes the legs don't run and GitHub does not consider the PR to be mergable.

I'm feeling there could be a way (or a hack) to let the required legs "pass" without building/running tests. Some of the ideas:

• Update the .cmd scripts that're run in CI to detect which files are modified (possibly by git reset --soft followed by git status --porcelain and parse the output. Then, based on the changed files, we either run the script as normal, or return 0. If we returned 0, then GitHub will be convinced that the leg was run and passed.
• Update the Azure yaml files in a similar manner, instead of using the triggers exclude, we may try wrapping the script in a condition:

NOTE: I'm not sure how hard this can get, and whether any of the two options can work. Just sharing my thoughts here :)

The runtime repository takes an approach similar to what you are suggesting. Essentially they have a script they run which more / less runs a git status call then sets a number of variables that represent the areas of the code that changed. That lets them condition later runs on items like only run this if libraries changed.

It's necessary for them as they have a giant repo and it pays off massively for them to partition this way. I'm not sure we'd get the same benefits here. Have to weigh it against the cost of having tigers / admins force merge doc changes that run into CI issues.