Hi,
Travis recently enabled a new auto cancellation feature.
If you commit a new change Travis can automatically cancel the old builds in the queue. That means you should get the results for the latest change faster.
See more details at the Travis blog [1].
To me it looks like a nice feature.
The only drawback is that if you really use the strict TDD approach (write a failing test first then create a fix, like I did here [2]) then you would have to wait a bit between pushing the test and the fix. At least until the first build starts.
But that is usually not the case is our workflow so it should not be an issue and we could use this feature by default.
So any reason why NOT using the auto cancellation feature? Otherwise I'd enable it globally for all Travis jobs...
Lada
[1] https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation [2] https://github.com/yast/yast-yast2/pull/570
Hi, I think it makes sense. If I use TDD approach, I run it locally and do not wait for travis.
Josef
On Tue, 25 Apr 2017 13:28:48 +0200 Ladislav Slezak lslezak@suse.cz wrote:
Hi,
Travis recently enabled a new auto cancellation feature.
If you commit a new change Travis can automatically cancel the old builds in the queue. That means you should get the results for the latest change faster.
See more details at the Travis blog [1].
To me it looks like a nice feature.
The only drawback is that if you really use the strict TDD approach (write a failing test first then create a fix, like I did here [2]) then you would have to wait a bit between pushing the test and the fix. At least until the first build starts.
But that is usually not the case is our workflow so it should not be an issue and we could use this feature by default.
So any reason why NOT using the auto cancellation feature? Otherwise I'd enable it globally for all Travis jobs...
Lada
[1] https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation [2] https://github.com/yast/yast-yast2/pull/570
On 25.04.2017 13:28, Ladislav Slezak wrote:
Travis recently enabled a new auto cancellation feature.
If you commit a new change Travis can automatically cancel the old builds in the queue. That means you should get the results for the latest change faster.
+1
The only drawback is that if you really use the strict TDD approach (write a failing test first then create a fix, like I did here [2]) then you would have to wait a bit between pushing the test and the fix. At least until the first build starts.
Does anybody do that with Travis? Isn't it a lot easier and faster to do it locally? So I don't see a downside here.
Kind regards
Dne 25.4.2017 v 13:28 Ladislav Slezak napsal(a):
So any reason why NOT using the auto cancellation feature? Otherwise I'd enable it globally for all Travis jobs...
Actually the autocancellation has now become the default at Travis [1].
(Originally I wanted to turn it on globally but at that time it was a Beta feature and the option was not accessible via the Travis API so I did not enable it. Now it has been enabled globally by Travis...)
[1] https://blog.travis-ci.com/2017-09-21-default-auto-cancellation
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-
Josef Reidinger -
Ladislav Slezak -
Stefan Hundhammer