Am 19.12.19 um 10:24 schrieb Andrey Semashev via Boost:
On 2019-12-19 03:20, Edward Diener via Boost wrote:
When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt.
Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?
I think, a great deal of Appveyor time is wasted due to it not cancelling queued jobs on subsequent commits, like Travis does. I don't think we can practically do anything about it, other than manually cancelling the unneeded jobs.
I was like: There must be an option! And there is: https://www.appveyor.com/docs/build-configuration/#rolling-builds “Rolling builds” are great for very active OSS projects with lengthy queue. 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. Other words, rolling builds make sure that only the most recent commit is built. For example, you do commit |A| to |master| branch - it’s being queued and then run. Then you do |B| commit to |master| branch while |A| is running - build of |A| will be cancelled immediately and |B| is queued. If you do another |C| commit while |B| is queued it will be cancelled and |C| queued. (Note that “Rolling builds” can only be enabled in the settings UI of a project and not via |appveyor.yml| and that the presence of |appveyor.yml| does not disable this UI setting.) So: Enable in UI