www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - CI: Why Travis & Circle

reply jmh530 <john.michael.hall gmail.com> writes:
I'm curious what the typical motivation is for using both Travis 
CI and Circle CI in a project is.

Thanks.
Nov 14 2019
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 14 November 2019 at 13:47:32 UTC, jmh530 wrote:

 I'm curious what the typical motivation is for using both 
 Travis CI and Circle CI in a project is.

 Thanks.


With the public availability of Github Actions I highly recommend 
it if you have open source project on Github. If is free and 
works well with D and Dub.

Kind regards
Andre
Nov 14 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 14 November 2019 at 17:06:36 UTC, Andre Pany wrote:

 [snip]

 With the public availability of Github Actions I highly 
 recommend it if you have open source project on Github. If is 
 free and works well with D and Dub.

 Kind regards
 Andre


I'm not that familiar with Github Actions, but I should get more 
familiar with it.

But my broader question is why both? Don't they both do largely 
the same things?

I was motivated to ask this by looking at the mir repositories, 
which have both.
https://github.com/libmir/mir
Nov 14 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 14 November 2019 at 17:32:27 UTC, jmh530 wrote:

 On Thursday, 14 November 2019 at 17:06:36 UTC, Andre Pany wrote:

 [snip]

 With the public availability of Github Actions I highly 
 recommend it if you have open source project on Github. If is 
 free and works well with D and Dub.

 Kind regards
 Andre


 I'm not that familiar with Github Actions, but I should get 
 more familiar with it.

 But my broader question is why both? Don't they both do largely 
 the same things?

 I was motivated to ask this by looking at the mir repositories, 
 which have both.
 https://github.com/libmir/mir


Most likely the reason is parallelism. Every CI service offers a 
limited amount of agents that can run in parallel, which limits 
the number of test matrix combinations that you can run in a 
reasonable amount of time. For example, many of the major D 
projects are tested across different OSes and several versions of 
D compilers. Additionally some CIs are faster than others. In my 
experience CircleCI is faster than TravisCI by a large margin.

Another reason is the different types of CI agents. Traditionally 
Travis CI was the first CI service that offered macOS agents for 
free for open-source projects. Now they have experimental Windows 
support as well. On the other hand Travis uses VMs which are 
often noticeably slower to boot than containers. (I think they 
also offered containers for a while, but for some reason they 
deprecated this offering).
CircleCI on the other hand has a really good support for 
containers and in my experience they start in about 1-2s after a 
commit is pushed (whereas VMs can take between anywhere between 
20-60s.

As Andre mentioned, GitHub Actions is a new player in the space, 
which offers an extremely generous amount of compute for public 
repos, courtesy of Microsoft Azure.
(Actually I think they offer exactly the same for public repos as 
what Azure Pipelines offers). However, GitHub Actions has the 
most catch up to do, if you exclude their raw compute power. 
Their UI is extremely bare bones and the configurability is 
lacking behind both CircleCI, SemaphoreCI and even Azure 
Pipelines. However, for most D projects what they offer should be 
a perfect fit.

As for Mir specifically, just check what commands are run by 
circle.yml and .travis.yml and you'll be able to understand 
whether there is actually a need for using multiple CI services:
https://github.com/libmir/mir/blob/master/circle.yml
https://github.com/libmir/mir/blob/master/.travis.yml

I may be wrong, but it seams that they should be able to 
consolidate their testing into just one CI service, but I would 
recommend holding off trying GitHub Actions for now and to go 
with Azure Pipelines, as GitHub's offering is not very stable 
yet. For example two days, due to some change on their side their 
CI completely stopped working on a public repo of mine. After 
researching I found that other people had similar issues (e.g. 
[1]), but fortunately, after contacting their support the issue 
was resolved one day later. In comparison, Circle CI, Semaphore 
CI and Azure Pipelines have been much more rock-solid in my 
experience.

[1]: 
https://github.community/t5/GitHub-Actions/GitHub-Actions-workflows-can-t-be-executed-on-this-repository/td-p/38153
Nov 16 2019
parent jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 16 November 2019 at 09:07:45 UTC, Petar Kirov 
[ZombineDev] wrote:

 [snip]

 Most likely the reason is parallelism. Every CI service offers 
 a limited amount of agents that can run in parallel, which 
 limits the number of test matrix combinations that you can run 
 in a reasonable amount of time. For example, many of the major 
 D projects are tested across different OSes and several 
 versions of D compilers. Additionally some CIs are faster than 
 others. In my experience CircleCI is faster than TravisCI by a 
 large margin.


Thank you for the very insightful answer.
Nov 16 2019
prev sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Thursday, 14 November 2019 at 13:47:32 UTC, jmh530 wrote:

 I'm curious what the typical motivation is for using both 
 Travis CI and Circle CI in a project is.

 Thanks.


Circle CI is more flexible but with quite limited free resources.
Nov 19 2019