Auto Cancellation : Get faster results by only testing your most recent build

[joshk]

It's not uncommon to have your waiting builds queue grow, especially if your team is pushing new code to GitHub every few minutes.

With Auto Cancellation, you can enable Travis to cancel waiting and outdated builds when new builds flow in from GitHub.

This setting can be enabled for Branch and Pull Request builds separately.

Builds will only be canceled if they are waiting to run, allowing for any running jobs to finish.

You can find this new setting on the Repository settings page.

This feature was released for beta testing soon on the 22nd of March. You can find the blog post announcement here: https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation

Please Note: We are looking at adding the ability to also cancel running jobs. If this is of interest to you and your team, please add the 🎉 emoji to this issue 😄

[jwg4]

Great feature. It would be nice to be able to see in the Build history whether a branch was auto cancelled or cancelled manually.

[pllim]

I turn this feature on, but then it keeps turning itself off again with no reason.

[joshk]

@pllim could you please email support@travis-ci.com and we can look into it

@jwg4 🤔 thank you for the good point. We can have a think about that as it could provide some value to make that change

[niccokunzmann]

In many cases, only the last build is important. I am grateful for this service, so I do not want it to run when it is useless. My hope: This feature will reduce the number of builds that are executed and not considered.

[aprescott]

@IgorMinar's comment about force pushes definitely aligns with my use case:

I often do work by pushing small commits to my PR branch frequently without even waiting for the results of the current run. This way I get to move quickly and can see build history to find out where I broke the build.

I do this fairly often. To avoid breaking git bisect over time, if a PR has multiple commits then I like to have Travis confirm that the build for each commit is green. The way I do that today is to push separate branch commits one by one to trigger separate builds. My understanding of the Auto Cancelation feature is that if I were to push a bunch of commits (say 5 or 6) in sequence, any not-started, queued builds would be canceled and I'd be missing CI status on some commits. I definitely consider that bad, so I wouldn't enable it for any repo.

What I'd like instead is for any build, including those currently active, to be canceled whenever the commits they're building are no longer reachable from a ref. As an example:

1. I rapidly 5 commits to Travis individually to trigger separate builds.
2. A few seconds later, I discover the whole branch needs a rebase.
3. I rebase, and re-push all 5 commits.

Whenever this happens, I'll manually cancel the 5 builds from step (1), to let the 5 builds from step (3) take their place, for two reasons. First, the commits are going to be-rebuilt anyway. Second, the original 5 builds are tied to their commits, but Travis won't be able to git checkout the commits and the build will error anyway, causing noise. If Auto Cancelation canceled builds for the non-reachable commit SHAs from step (1) (leaving any that are still reachable), that would be perfect, and I think would make great default behavior.

[joshk]

@aprescott thanks for the feedback. This feature is unlikely to be added in the near future. It is actually fairly complicated to know when a sha is no longer reachable. A force push might over make one sha no longer accessible, or maybe 10, there isn't a reliable way to check.

[kaizhu256]

this feature rocks! i'm applying automated rolling updates to 5000+ repos, and it solves the PAINPOINT of accidentally triggering builds twice or thrice for the same repo : )

[nathandunn]

+1

[javydreamercsw]

This works amazingly. Even in my project that I'm alone I see the queue grow. Can't imagine one with multiple developers. It saves both time and resources.

Keeps getting better!

[andrasq]

this is a great feature, it should be made the default. Not much point in running the tests for a branch that was just overwritten. At times I know I push many small edits (esp when updating the Readme, when I like to proofread the formatted copy)

[chetbox]

We've been using this for our iOS builds and have noticed the latest commit being cancelled occasionally, while a previous commit continues to build. Could be a race condition?

[grosser]

Please add the option to cancel even running builds ... we have a repo that does 40 parallel jobs and it keeps clogging up the build pipeline ... ideally make canceling all active builds the default ... since that would be most resource-saving and most people do not care about results for something they just overwrote anyway ...

[m-kuhn]

Please add the option to cancel even running builds ... [snip] ... ideally make canceling all active builds the default.

If this is introduced, this should be an option and the current approach should still be available (default or not). For long-running builds it's interesting to get quicker feedback about issues on the branch even if it's from a previous build.

[joshk]

@grosser Hey Michael, yep, that option will come soon!

[joshk]

Thank you everyone for your amazing feedback!

We have taken this feature out of beta, and will be addressing the request to add the ability to cancel running builds shortly.

Happy Building

The Travis CI Team

[ezzatron]

Will this make it to enterprise at some point?

[alecbz]

Any update on cancelling running builds?