I am looking at the Auto Cancellation feature of Travis and was wondering what the logic was behind limiting this feature to queued builds only. It seem that it would make sense to cancel builds based on previous version of the branch if the branch has been updated, given of course that you’re able to provide exceptions for some branches like master. Sorry if I am missing something obvious but any feedback would be appreciated.
The current behavior (only cancelling a build that has not started yet when a new commit is pushed) exists because typical build run time is much longer (hours) than build start time (seconds to minutes).
If you instead cancel a build whenever a new commit is pushed, even when it’s already running, very few, if any, builds will ever finish, making CI useless.
I would agree with that if we’re not talking about PR builds. There definitely exist scenarios where when I am pushing a commit that updates an existing PR - I no longer care about build result of the previous commit in that PR. Ultimately, yes it would still be nice to have that build result for various reasons, but it would not allow me to merge my code anyways, and is essentially, in many cases, more trouble that its worth compared to the resources on the build farm that it takes up. I know its not ideal when a developer pushes another several commits after they just created a PR (to fix a obvious issue, or to add a comment or a readme point they missed) but it does happen quite often on some teams. All I am saying that it would be a nice to have option for some teams, especially with shorter build times.
I would love to have a cancellable: true flag in jobs which would cancel the running build if Auto Cancellation triggers. false could be the default, so it’s not a breaking change.
Some builds should not be cancellable (killing something in the middle of a deployment).
If you have stages like
test (cancellable: true)
build (cancellable: true)
deploy (cancellable: false)
making test and build cancellable, would acutally cancel everything and restart for the next commit.
if the build is actually running deploy, it would wait for deploy to finish before going to the next one.
I would be extremly valuable as some long running jobs (e2e) can actually be cancelled.
It would also save Travis some money and us some time