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 😄

[svenfuchs]

This is now live, and documented: https://docs.travis-ci.com/user/customizing-the-build/#Building-only-the-latest-commit

Blog post: https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation

[PeterDenton]

If there are pushes on different branches will there be cancellations? Example: I push up my dev branch with a new commit. I then merge it into my master branch and push that up. Meanwhile, the dev branch is queued and a new push arrives on the master branch. Does the dev branch still run? The description here and on the broadcast are a bit unclear on this point.

In any case, nice update, thanks.

[crunis]

Is there a way to activate this via API? we want it in all our builds!

@PeterDenton if that was the case, I would consider it a bug. The announced feature says PER BRANCH or PER PR, not PER WHOLE REPO.

[joshk]

Hi @PeterDenton and @crunis

@PeterDenton, @crunis is correct that this is applied per branch. Supporting the use case you described isn't super simple, but can be something for us to consider for the future.

@crunis yes, we do have an API. You can find docs at https://developer.travis-ci.org, specifically https://developer.travis-ci.org/resource/user_setting#User%20setting. Although I notice that the docs need some updating (we are releasing these docs next week, along with our new V3 API)

[crunis]

@joshk managed to use the API, thanks !

The "discoveries" I made that I would like to see in the documentation:

• GET /repo/{repository.id)/settings returns all the available attributes
• The 2 new attributes are auto_cancel_pushes and auto_cancel_pull_requests
• One can update their values with something like :
  curl -X PATCH -H "Content-Type: application/json" -H "Travis-API-Version: 3" -H "Authorization: token xxxxxxx" -d '{ "user_setting.value": true }' "https://api.travis-ci.com/repo/{repository.id}/setting/auto_cancel_pull_requests"

repository.slug can be used instead of the repository.id, but then we have to use %2F as the user / repo_name separator

[joshk]

Thanks for the feedback @crunis

I've looped in @renee-travisci who is part of our awesome engineering team, and leads a lot of the development on the API.

Glad you got it all working!

[jleclanche]

@joshk Would also love this in all my builds. Is there a plan to turn it on by default? It's a lot of work to change every single repo setting, and then keep changing it for any new repo we add.

[joshk]

@jleclanche Once this is out of Beta this is definitely something I would be interested in. Thanks for the suggestion!

[lbergelson]

👍 We've been wanting a feature like this for a while.

[LiNk-NY]

@joshk, I would also suggest that this be the default setting. It conserves precious resources.
I'm grateful for the Travis-CI project and team! 😄

[joshk]

Hey @LiNk-NY, yep, that was my thinking too! 😃

[grooverdan]

Nice.

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

What isn't cancelled is waiting jobs that are part of a matrix build where one job has started. I.e. if any job has started in a matrix build the Auto Cancellation will wait for the entire matrix to finish.

I think the outstanding jobs of a build matrix should be cancelled but still allow the started jobs to complete.

[megies]

@joshk, I would also suggest that this be the default setting. It conserves precious resources.
I'm grateful for the Travis-CI project and team! 😄

+1 For "default setting" and/or possibility to set it in the yaml. Thanks for the feature in any case @joshk!

[krymen]

Great work Travis team! I agree with @LiNk-NY and @megies -- it should be the default setting.

[Fryguy]

Very happy to see this...can't wait to delete our bot code

[joshk]

Hi @grooverdan, thanks for the feedback!

The current iteration of this feature allows for builds to finish if they have started. There is a possibility, especially if you have a busy team, that a build might never finish because your build (which might run for a long time) always gets cancelled by a new build.

The second iteration of this feature will allow for running builds to be automatically cancelled when a new build comes in.

@megies Thanks for the feedback. We are unlikely to add this to the .travis.yml we want to keep it a bit more focused on build configuration vs account settings.

[drdanz]

Very useful feature, thanks!

I'd like to have a better control on the branches where this is enabled, in particular I'd like to be able enable it for all branches with the exception of the main branches, for which I want to test all the commits.

[Terry-Weymouth]

You guys rock. Must have seem me and other frantically reaching for that cancel button. Maybe setting on by default on, with override in settings and/or yaml file? That would be great!

[grooverdan]

@joshk I'm not sure you have the same concept in mind as me. The concept i'm trying to convey (with job overloaded too many ways so I'm hoping this is consistent with current terminology) is: when a build starts it starts up to 5(4?) jobs. There may be more in the build same build that are there and haven't started. Auto Cancellation should cancel any jobs that are part of the same build that haven't started and leave the remaining jobs to finish.

[ljharb]

This feature is awesome!

I already submitted this feedback via another channel, but:

I can't safely use "auto cancel branch builds" unless I can enumerate the branches on which I never want this to happen - in other words, master, gh-pages, etc. I only want autocancellation on feature branches.

[robdvr]

Thank you for rolling this out! Great work!

[nclopezo]

Great idea, thank you!

[joshk]

@akaralar Thanks for the feedback. We plan to support the ability to cancel currently running Jobs in the near future.

@peternewman Sorry to hear that, could you email support@travis-ci.com and we can look into it.

@lneuhaus Sorry to hear that you are having issues with this feature. Is the description at the top, or where you enable this feature, not clear? Could you email support@travis-ci.com explaining the problem further and we can look into it. Thanks a bundle!

[LefterisJP]

@joshk Quick question about this feature. What is the expected behavious when auto cancelation is ON, there is no currently running build in a branch and you force push into it by amending the last commit but not adding any new commits?

Will a build properly run?

[joshk]

Hi @LefterisJP, sorry, I'm not sure I understand. You mention force pushing by amending the last commit, was this last commit also pushed to GitHub? Travis isn't running any builds, is that expected?

[LefterisJP]

Yeah so the last commit was pushed and built succesfully. Then when you amend it locally and force push to github again you would expect Travis to generate a build right even if autocancelation is on?

We had an issue where Travis was not running a build, but I think we found the problem and it's not related to autocancelation.

[dwsteele]

I would like to be able to disable this for certain branches, like integration and master. For all other branches it is certainly the way to go. Any way to do that?

[joshk]

@dwsteele Thanks for the feedback. There currently isn't a way to do that, but I do like that idea. I will note that for the second round of development.

[hughperkins]

Question: what will happen to the place of jobs in the queue?

• if queued jobs will get pulled, and the new jobs get added to the tail of the queue, I'd rather just leave my jobs in the queue, at least get feedback earlier, even if for older jobs
• on the other hand, if you replace whichever job is nearest the head of the queue with the latest commit, that seems open to abuse

For now, I'm just posing the question :-)

[joshk]

@hughperkins the feature is fairly simple in that it will cancel jobs for the entire Build, and add the new Build to the end (tail) of the queue.

[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?