thanks for raising this, @driazati ! I am wary of abusing a mechanism like this, but given how slow TVM CI is, I do agree that having a way to quickly fix or revert PRs that cause build breakages is a good thing. I’m in support of merging such a mechanism.
I do think we should include documentation that guides when it’s okay and not okay for a committer to use this power. I am also wondering if it’s possible to indicate this more prominently (e.g. can Jenkins post up on the PR saying it was skipped? can we require it to be in the PR title?).
I’d suggest these situations when you could skip CI:
- The original one: when a previous PR breaks CI and the PR in question is either a rollback or a small fix-forward which has been verified by the TVM committer locally (or the TVM committer trusts the author to have verified the fix). Local verification should not be done when the breakage involves a test that uses the GPU.
- When you are updating a CI image and it has already passed CI in another context.
When a committer skips CI, they should monitor the next main build at https://ci.tlcpack.ai.
For all other cases, I’d like us to continue to work to improve the speed of the CI rather than encouraging the community to bypass the CI. Bypassing the CI will create a different problem (where we don’t have visibility into what is slow). I’d like to encourage people to be very judicious when using this power.
Tagging a few others who may have thoughts here: @leandron @mousius @manupa-arm @grant-arm @mbaret @junrushao @tqchen