Should we run fewer CI workflows on main itself?

[cassidyjames]

If we're running CI on each PR, requiring it to pass before merging, and then re-running CI on main, aren't we duplicating our GitHub Actions and wasting quite a bit of compute?

We could require PRs to be up-to-date with main before merging, which would mean that they need to pass CI when merged into main, and then not need to re-run the same CI workflows on main itself… because I'd rather catch failing CI on the PR than after it's merged, anyway.

Is there a subset of CI checks that we always want to run on main, while leaving the rest to PRs? Would it disrupt anyone's workflow to require PRs to be up-to-date with main before merging? Would this change just cause extra CI runs on PRs themselves since there's be more updating them before merging? 🤔

[juanmrad]

I can see your point here, but I’d keep CI running on main rather than require every PR to be up to date before merging. The latter gets increasingly disruptive as more people contribute: when one PR merges, other ready PRs become stale. Their authors ( or maintainers ) must update their branches, rerun CI, and wait. If another PR merges first, the process needs to be repeated again.

I also don’t expect this to save CI costs. It shifts CI runs from main to updated PR branches, and busy periods could trigger several full runs for a single PR before it merges. Running CI on main lets us merge PRs without that repeated work while still checking the combined result.

There is definitively some benefit of ensuring everything merged is green on the PR before main, but also given we do releases and not CI/CD we can do forward fixes as needed.