From @jayvdb on Tue Jul 19 2016 03:32:28 GMT-0400 (EDT)
Appveyor has the option of skipping builds for commits that are stale.
“Whenever you do a new commit to the same branch OR pull request all current queued/running builds (preferably only queued, but not yet running ones) for that branch or PR are cancelled and the new one is queued.”
This is very helpful for open source projects to avoid lots of little commits eating into the 200 build limit.
Copied from original issue: https://github.com/bitrise-io/bitrise.io/issues/47
1 Like
From @viktorbenei on Tue Jul 19 2016 03:39:27 GMT-0400 (EDT)
Awesome idea! Make sure that you vote on it here, on GitHub 
From @viktorbenei on Tue Aug 16 2016 11:47:06 GMT-0400 (EDT)
Hi,
Could you add a bit more description? Just so that it’s clear for others too what this is about - can help you get more votes too
From @jayvdb on Tue Aug 16 2016 18:55:28 GMT-0400 (EDT)
My reason for requesting this is I run a training program @besutkode for high school students, most who are using git for the first time. For the first few exercises I let them commit like crazy in a shared private repo, and they hit the 200 build limit really quickly. Only in the third activity do I teach them commit cleanliness, after they are already used to the git basics, and have shown competency in coding.
From @viktorbenei on Wed Aug 17 2016 02:06:16 GMT-0400 (EDT)
Thanks for the details - I made an edit in your original description, just to highlight that this would not abort running builds, only queued ones (I’d definitely prefer a system which does not abort running builds, only queued-but-not-yet-running ones - we call these “on hold”).
From @jayvdb on Wed Aug 17 2016 03:48:20 GMT-0400 (EDT)
For bitrise, which has a limit on the number of builds, it wouldnt be semsible to kill a running build as it has already decremented the number of free builds - may as well let it run to completion.
From @viktorbenei on Wed Aug 17 2016 03:49:56 GMT-0400 (EDT)
As well as, this can prevent the situation when during a busy day your team continuously push new commits, which could lead to no checks for a long time if it’d always abort the running build.
From @bootstraponline on Fri Oct 28 2016 12:47:02 GMT-0400 (EDT)
> (I’d definitely prefer a system which does not abort running builds
The entire point of this feature is to abort running builds, to reclaim the executors for the latest commit.
From @brentleyjones on Fri Oct 28 2016 13:31:41 GMT-0400 (EDT)
I think a default could be to skip queued builds. I personally, by default, wouldn’t want the system to kill an already executing build.
From @bootstraponline on Fri Oct 28 2016 13:38:49 GMT-0400 (EDT)
I don’t mind as long as there’s an option. There’s no point to letting a build execute if we don’t care about the build.
From @brentleyjones on Fri Oct 28 2016 13:49:05 GMT-0400 (EDT)
I agree. For me, all builds on master (maybe even queued ones?) I would want to build. In a pull request I would want to kill all, even active ones, since I only care about the latest code.
From @bootstraponline on Fri Oct 28 2016 14:00:18 GMT-0400 (EDT)
Sounds good.
From @jayvdb on Sat Oct 29 2016 01:00:17 GMT-0400 (EDT)
Perhaps a way to move forward is to have an binary option for bitrise to kill all (queued and running) stale builds, except on a set of excluded branches, with master as the default excluded branch. (and treat PR’s as a separate branch for this purpose)
That should make 80% of people happy
Additional configuration, for the other 20%, of when to kill stale builds on master and other important branches could then be deferred to another enhancement, which will be tricker to get right.
From @viktorbenei on Sat Oct 29 2016 02:59:15 GMT-0400 (EDT)
Sounds good, now we “just” have to figure out a way to make this configuration as easy and straight forward to use as possible, especially because misconfiguration could cause quite bad results (e.g. a deployment gets aborted).
From @bootstraponline on Mon Oct 31 2016 11:27:00 GMT-0400 (EDT)
> Sounds good, now we “just” have to figure out a way to make this configuration as easy and straight forward to use as possible,
I think for the PR use case, a toggle that aborts old builds (disabled by default) when new commits are pushed is simple enough. It’s the non-PR use case that’s more complex.
This would be great for us. We have 2 concurrent builds. Our workflow is:
- Create PR on separate branch. A build runs every time the PR is updated and includes Appetize links. Takes about 30 minutes
- Merge PR to master. A build runs to provide Appetize links with the latest code. Takes about 40 minutes
There are two problems.
- Sometimes the dev pushes multiple times to their PR and builds get queued despite having no difference in code when each build finally runs.
- We get lots of builds queued for master. The biggest downside is that new PRs often don’t get their builds started for hours while they wait for unnecessary builds to completed. Currently we do a lot of manual aborts but it’s something we don’t want to have to do
1 Like
Thank you for the insights/use case @stevepotter it’ll definitely help us a lot when we get to work on this feature!
Team city has a feature to throttle the requests, eg: to have a time until which the triggered build should not start, making room for multiple merges to be made from PRs. This will be really helpful for both us users and bitrise platform saving resource times. With sane defaults this will be helpful to many
1 Like
I agree @srivathsaharish, but for this to work reliably you’d also have to define a “max wait time”, to avoid the situation when you keep pushing commits so frequently, that no build is started for a really long time. IMO it’s still better to have “checkpoint” builds (every X mins) in this case than no builds at all, so that you can see roughly where it starts to break if it would fail.
Is there any update on this? First the issue was on user voice (#3 in terms of votes), then github, and finally discourse. Each time we lost a ton of people (originally 79 votes and now only 5).
https://bitrise.uservoice.com/forums/235233-general/filters/top
1 Like
