We had previously tried to avoid what we saw as duplicate runs of CI on each PR commit. We didn't realize (or didn't document) that the two runs represent the actual branch (on: push) vs a hypothetical merge (on: pull_request).
Only running on: pull_request however, meant that CI would not run unless the branch could cleanly merge with trunk, which is not a great requirement for running CI.
With this change, we can try out running on both. It will mean we have a lot of checks, and it will mean that we maybe need to adjust .mergify.yml to be sure that it doesn't auto-merge a PR that can't merge. (Well, I suppose it wouldn't do that; but we don't want it to try, and fail, either.)
We had previously tried to avoid what we saw as duplicate runs of CI on each PR commit. We didn't realize (or didn't document) that the two runs represent the actual branch (
on: push) vs a hypothetical merge (on: pull_request).Only running
on: pull_requesthowever, meant that CI would not run unless the branch could cleanly merge withtrunk, which is not a great requirement for running CI.With this change, we can try out running on both. It will mean we have a lot of checks, and it will mean that we maybe need to adjust
.mergify.ymlto be sure that it doesn't auto-merge a PR that can't merge. (Well, I suppose it wouldn't do that; but we don't want it to try, and fail, either.)