tag:help.appveyor.com,2012-11-13:/discussions/problems/586-cancel-queued-builds-for-old-commits-of-the-same-branchAppVeyor: Discussion 2018-08-25T02:17:11Ztag:help.appveyor.com,2012-11-13:Comment/339041982014-07-25T13:30:59Z2014-07-25T13:30:59ZCancel queued builds for old commits of the same branch<div><p>For information here is the queue for the scikit-learn
project:</p>
<p><a href=
"https://ci.appveyor.com/project/ogrisel/scikit-learn/history">https://ci.appveyor.com/project/ogrisel/scikit-learn/history</a></p>
<p>Each commit takes 4 x 15min, so filtering redundant queued jobs
would help a lot.</p>
<p>Alternatively would there be a way to not triggers builds for
commits that happen in pull requests but only consider direct
commits in the white-listed branches?</p></div>olivler.griseltag:help.appveyor.com,2012-11-13:Comment/339041982014-07-25T13:39:35Z2014-07-25T13:39:35ZCancel queued builds for old commits of the same branch<div><p>Great idea with removing "queued" commits if there is newer one.
Also, there is a request from other customer to have "quite time"
feature - when builds start running at some time after last commit.
Maybe this would work better?...</p>
<p>Re: pull requests - edit webhook settings at GitHub and disable
"Pull requests" event.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982014-07-27T17:54:02Z2014-07-27T17:54:02ZCancel queued builds for old commits of the same branch<div><p>I think both features would help.</p>
<p>The quiet time could ideally be configurable, 0 (disabled) by
default.</p></div>olivler.griseltag:help.appveyor.com,2012-11-13:Comment/339041982014-07-30T08:43:53Z2014-07-30T08:43:55ZCancel queued builds for old commits of the same branch<div><p>Redundant jobs have saturating our queue:</p>
<p><a href=
"https://ci.appveyor.com/project/ogrisel/scikit-learn/history">https://ci.appveyor.com/project/ogrisel/scikit-learn/history</a></p>
<p>I had to cancel all the queued jobs and disable appveyor CI for
now otherwise all build report lag by several days rendering them
mostly useless.</p></div>olivier.griseltag:help.appveyor.com,2012-11-13:Comment/339041982014-07-30T12:30:48Z2014-07-30T12:30:48ZCancel queued builds for old commits of the same branch<div><p>Yeah, it doesn't look good.</p>
<p>Does builds history (<a href=
"https://ci.appveyor.com/project/ogrisel/scikit-learn/history">https://ci.appveyor.com/project/ogrisel/scikit-learn/history</a>)
correctly reflect activity on the project (no missing or wrong
commits)?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982014-07-30T14:31:55Z2014-07-30T14:32:01ZCancel queued builds for old commits of the same branch<div><blockquote>
<p>Does builds history (<a href=
"https://ci.appveyor.com/project/ogrisel/scikit-learn/history">https://ci.appveyor.com/project/ogrisel/scikit-learn/history</a>)
correctly reflect activity on the project (no missing or wrong
commits)?</p>
</blockquote>
<p>I cancelled all the queued build manually and disabled all new
builds from the settings of the project. But other than that they
are all legit commits (most of them pull requests to the master
branch).</p>
<p>Would it be possible to only build the master branch without the
commits from the incoming pull requests?</p></div>olivier.griseltag:help.appveyor.com,2012-11-13:Comment/339041982014-07-30T14:33:02Z2014-07-30T14:33:02ZCancel queued builds for old commits of the same branch<div><p>Yes, disable "Pull requests" event on GitHub webhook settings
page.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982014-07-31T11:36:03Z2014-07-31T11:36:06ZCancel queued builds for old commits of the same branch<div><p>Alright thanks, that should help a lot in the short term.</p></div>olivier.griseltag:help.appveyor.com,2012-11-13:Comment/339041982014-07-31T11:51:49Z2014-07-31T11:51:49ZCancel queued builds for old commits of the same branch<div><p>So, removing queued builds would be an acceptable solution for
you? Should we consider different branches and PRs as different
queues? For example, let's suppose I have the following in the
queue:</p>
<ul>
<li>PR #1 - v1.0.4 - queued</li>
<li>master - v1.0.3 - queued</li>
<li>dev - v1.0.2 - queued</li>
<li>master - v1.0.1 - running</li>
</ul>
<p>what if someone submits to "master" branch - should we delete
both "dev 1.0.2" and "master 1.0.3" builds before inserting "master
1.0.5"?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982014-07-31T11:58:18Z2014-07-31T11:58:20ZCancel queued builds for old commits of the same branch<div><p>I would just cancel the queued master build: v1.0.3 in this
case.</p></div>olivier.griseltag:help.appveyor.com,2012-11-13:Comment/339041982016-07-24T17:38:10Z2016-07-24T17:38:12ZCancel queued builds for old commits of the same branch<div><p>Hi. Is this issue is resolved by a way or another? I mean that
any new commit for a certain branch will 'cancel' current build of
that branch if exist.</p></div>Cyberiumtag:help.appveyor.com,2012-11-13:Comment/339041982016-07-25T06:21:47Z2016-07-25T06:21:47ZCancel queued builds for old commits of the same branch<div><p>Yes, there is "Rolling builds" option on General tab of project
settings.</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982017-03-28T19:20:11Z2017-03-28T19:20:16ZCancel queued builds for old commits of the same branch<div><p>Rolling builds aren't quite what I want. From the docs:</p>
<blockquote>
<p>Whenever you do a new commit to the same branch OR pull request all current queued/running builds for that branch or PR are cancelled and the new one is queued.</p>
</blockquote>
<ol>
<li>Builds which have already started shouldn't be canceled.<br></li>
<li>A PR to branch <code>xyz</code> shouldn't cancel queued builds on branch <code>xyz</code> and vice versa<br>
a. However, subsequent commits to the PR should cancel <em>queued</em> builds <em>for that PR</em>. Similarly, additional commits directly to branch <code>xyz</code> should cancel <em>queued</em> builds on <code>xyz</code>.</li>
</ol>
<p>For example, somebody pushing 5 times to a PR over a short period of time shouldn't overwhelm the queue on the master branch. It also shouldn't kill a <em>running</em> build on that PR which started before the 5 pushes.</p>
<p>Another example: Suppose a build on master takes ~20 minutes and somebody pushes to master (or submits a PR to master) every 15 minutes. My understanding is a rolling build setup would kill every build before it has a chance to finish. The build system would always be busy without giving any feedback.</p></div>Jake Mitchelltag:help.appveyor.com,2012-11-13:Comment/339041982017-05-03T08:19:07Z2017-05-03T08:19:08ZCancel queued builds for old commits of the same branch<div><p>I don't fully understand why you only want to cancel queued builds and not running builds within the same branch. Purely for the feedback? Why? You won't get any feedback for the builds removed from the queue either yet those are arguably more important since they are for more recent commits. I agree it would be interesting to not have branches interact with PRs. But suppose I push one commit and 2 minutes later another one and 3 minutes later a third one, I'd either want to see the results of all 3 commits, or just for the last one. Not for the first one and the third one.</p></div>stijntag:help.appveyor.com,2012-11-13:Comment/339041982017-05-03T16:57:38Z2017-05-03T16:57:39ZCancel queued builds for old commits of the same branch<div><blockquote>
<p>suppose I push one commit and 2 minutes later another one and 3 minutes later a third one, I'd either want to see the results of all 3 commits, or<br>
just for the last one. Not for the first one and the third one.</p>
</blockquote>
<p>Let's also suppose each build takes 50 minutes. If all three builds ran<br>
back-to-back it would take about 2.5 hours, and there's a good chance the<br>
committer will have signed off or moved on to other tasks.</p>
<p>On the other hand, not building the second commit saves 50 minutes, and yet<br>
we get feedback about its changes within 1 hour and 40 minutes. If the<br>
build fails it's true that suddenly two commits (2 and 3) are suspect, but<br>
typically commits made to the same PR over such a short period of time<br>
aren't massive. Timely feedback can often be more important than precise<br>
feedback. With adequate error reporting in the build log there's a good<br>
chance the error could be identified within 50 minutes, even with the<br>
changes combined.</p>
<p>If the 1:40 vs 2:30 trade-off isn't compelling, suppose there were 8<br>
commits within a 50 minute period. In that case building only the first and<br>
last commits would still take 1 hour and 40 minutes, yet building each<br>
commit would take 6 hours and 40 minutes. All of this assume the build<br>
resources are dedicated to that particular PR, but there are often multiple<br>
PRs. The longer the time demands, the more likely it is to get interrupted.</p></div>Jacob Mitchelltag:help.appveyor.com,2012-11-13:Comment/339041982017-05-04T17:30:49Z2017-05-04T17:30:49ZCancel queued builds for old commits of the same branch<div><p>Wait a minute, guys. Right now PRs and branches do not interfere. Commits to PR do not cancel builds of "base" branch of this PR. Similarly, commits to branch "A" do not cancel builds of PRs with "base" branch "A". Or can you prove otherwise?</p>
<p>I appreciate your thoughts. From all said above and in <a href="https://github.com/appveyor/ci/issues/1529">this issue</a> I understand that we are missing yet another option for rolling builds: <code>Do not cancel running builds</code>. Does it sound correct or I'm missing something?</p></div>Feodor Fitsnertag:help.appveyor.com,2012-11-13:Comment/339041982017-05-04T18:23:55Z2017-05-04T18:23:55ZCancel queued builds for old commits of the same branch<div><p>That sounds correct to me. The "do not cancel running builds" option makes rolling builds have the same behavior as I've seen/used with Jenkins and Buildbot.</p>
<p>The current behavior regarding PRs and branches seems correct to me.</p></div>accountstag:help.appveyor.com,2012-11-13:Comment/339041982017-05-07T22:59:59Z2017-05-07T22:59:59ZCancel queued builds for old commits of the same branch<div><p><code>Do not cancel running builds</code> feature has been deployed.</p></div>Feodor Fitsner