Related to #961

👍

This sounds like a lot of complexity to me. I'd propose we have better control about cancelling all running jobs as proposed in other tickets.

I'd love to have it cancel any pending or running builds of the same branch when a newer commit comes in.

👍 for this as well. As I wrote in #2505, my use case is more around PRs and rapid fire commits, and my thought on the approach was if a new PR build is added to the queue, then upon being added, it would go out and cancel other pending and running builds for the same PR#.

👍 I often push several commits at once and would rather have only the most recent commit built. It also shortens the build queue for everybody else, so its a win win situation.

There is a huge benefit in testing each push and not cancelling a build just because a newer push has come through, and that is you can see which push broke the build.
I'm not a huge fan of adding extra complexity, but would be happy to work with someone on prototyping this feature (when I say working, I more mean helping guide and code review).

I think the use case is primarily for when refs are no longer available due to an amended commit + force push, otherwise you end up with a bunch of error'd builds and a waste of queue time which could be devoted to a build you actually expect/hope to pass.

@joshk that might be a benefit, but if I have to wait 45 minutes to know if perhaps the latest build fixes the issue it's not all that helpful

@joshk

1. New commits into PR. As a developer, I just want to make sure my branch works for the full test suite. I can run the specific tests locally to find which commit failed in order to fix it. I'll probably force-push a clean commit anyway when I find it.
2. Force-commits into PR. Same, plus what @caitp said.
3. Merge into main line (master). As a maintainer, one might want to know which merge broke the build. However, for me, I tend to review a bunch of PRs at once and merge 3 or 4 in a row. Since the PRs were green before merge, I just want to know the latest on the main line.
4. Direct commits onto main line. We don't do these, but some projects do. I can see possibly wanting to know which one broke the build. I guess one could use [skip ci] for things like README commits on the main line.

To me, I see two high level use cases that may differ in usage...PRs and the main line branch. One option for each might be flexible enough.

👍

👍

👍

👍 especially when it is a forced push after an amend / rebase

👍

👍 Dropped $5 on this issue.
https://www.bountysource.com/issues/848166-option-to-cancel-pending-builds-if-a-newer-build-exists

Hello. @grosser has come up with an interim solution https://github.com/grosser/travis_dedup while we work on a long-term fix.

Thank you!

Closing this issue for now, as we have no immediate plans to add this feature.

Should we add it to the roadmap eventually, we'll make sure to update this ticket.