About authorizing CircleCI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

About authorizing CircleCI

Boost - Dev mailing list
Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
much faster than Travis.


Is someone using it? What is your feedback?

If the feedback is positive, could someone authorize CircleCI to access
boostorg?


Best,

Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
On Tue, Mar 6, 2018 at 11:40 AM, Vicente J. Botet Escriba via Boost <
[hidden email]> wrote:

> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
> much faster than Travis.
>
>
> Is someone using it? What is your feedback?
>
> If the feedback is positive, could someone authorize CircleCI to access
> boostorg?
>

We've been building the Boost releases with CircleCI for more than a year.


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 06/03/2018 17:40, Vicente J. Botet Escriba via Boost wrote:
> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
> much faster than Travis.
>
> Is someone using it? What is your feedback?

I didn't find CircleCI compelling enough to leave Travis.

Appveyor are running a private Linux beta though. Appveyor understands
your XML test results output e.g. JUnit XML, and thus tells you exactly
what test failed. Appveyor can publish artifacts like prebuilt binaries.
Appveyor is lightning quick for the Windows builds at least, it often
completes - including all testing - before the Travis build job has begun.

You are probably also already using Appveyor, so it may be quicker to
add in the Linux support than implementing CircleCI support.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vicente J. Botet Escriba Via Boost wrote:
> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
> much faster than Travis.
>
>
> Is someone using it? What is your feedback?
>
> If the feedback is positive, could someone authorize CircleCI to
> access boostorg?

We're using it at Boost.Geometry since Jun 2015. The reason is we have
many quite extensive tests which fail at Travis due to time and memory
constraints.

Adam

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :

> Vicente J. Botet Escriba Via Boost wrote:
>> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
>> much faster than Travis.
>>
>>
>> Is someone using it? What is your feedback?
>>
>> If the feedback is positive, could someone authorize CircleCI to
>> access boostorg?
>
> We're using it at Boost.Geometry since Jun 2015. The reason is we have
> many quite extensive tests which fail at Travis due to time and memory
> constraints.

yes, this si the main concern.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 06/03/2018 à 19:19, Rene Rivera a écrit :

> On Tue, Mar 6, 2018 at 11:40 AM, Vicente J. Botet Escriba via Boost
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi, recently I heard of CircleCI (https://circleci.com/) and it
>     seems much faster than Travis.
>
>
>     Is someone using it? What is your feedback?
>
>     If the feedback is positive, could someone authorize CircleCI to
>     access boostorg?
>
>
> We've been building the Boost releases with CircleCI for more than a
> year.

I was not aware. So what I need to do to build Boost.Thread with CircleCI?
I've a PR to introduce it (https://github.com/boostorg/thread/pull/213).

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 06/03/2018 à 20:46, Niall Douglas via Boost a écrit :
> On 06/03/2018 17:40, Vicente J. Botet Escriba via Boost wrote:
>> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
>> much faster than Travis.
>>
>> Is someone using it? What is your feedback?
> I didn't find CircleCI compelling enough to leave Travis.
I was not suggesting this for all. I just wanted we had the ability to
do it for specific libraries if the authors want to do it.
>
> Appveyor are running a private Linux beta though.
I want Linux and MacOs builds. In particular I have a lot of issues with
timing with Travis MacOs.
Boost.Thread takes too long with Travis Linux (sometimes it reaches the
50min limit). The same test with CircleCi takes 10-15 min.
> Appveyor understands
> your XML test results output e.g. JUnit XML, and thus tells you exactly
> what test failed. Appveyor can publish artifacts like prebuilt binaries.
> Appveyor is lightning quick for the Windows builds at least, it often
> completes - including all testing - before the Travis build job has begun.
>
> You are probably also already using Appveyor, so it may be quicker to
> add in the Linux support than implementing CircleCI support.
I use it for Windows, yes. It takes too long also.
I'll take a look at how to do it.

Thanks,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 7 March 2018 at 06:42, Vicente J. Botet Escriba via Boost
<[hidden email]> wrote:
> Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :
>>
>> We're using it at Boost.Geometry since Jun 2015. The reason is we have
>> many quite extensive tests which fail at Travis due to time and memory
>> constraints.
>
>
> yes, this si the main concern.

I was seeing warnings on circleci about our usage going over capacity
last month. I think it measures across the organisation. The bulk of
the usage probably is the snapshot build (it does it twice for every
commit), but it's something to be wary of.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :

> Vicente J. Botet Escriba Via Boost wrote:
>> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
>> much faster than Travis.
>>
>>
>> Is someone using it? What is your feedback?
>>
>> If the feedback is positive, could someone authorize CircleCI to
>> access boostorg?
>
> We're using it at Boost.Geometry since Jun 2015. The reason is we have
> many quite extensive tests which fail at Travis due to time and memory
> constraints.
Adam, what I must do for Boost.Thread?
I've already this PR https://github.com/boostorg/thread/pull/213.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
On Wed, Mar 7, 2018 at 1:41 PM, Vicente J. Botet Escriba via Boost <
[hidden email]> wrote:

> Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :
>
>> Vicente J. Botet Escriba Via Boost wrote:
>>
>>> Hi, recently I heard of CircleCI (https://circleci.com/) and it seems
>>> much faster than Travis.
>>>
>>>
>>> Is someone using it? What is your feedback?
>>>
>>> If the feedback is positive, could someone authorize CircleCI to access
>>> boostorg?
>>>
>>
>> We're using it at Boost.Geometry since Jun 2015. The reason is we have
>> many quite extensive tests which fail at Travis due to time and memory
>> constraints.
>>
> Adam, what I must do for Boost.Thread?
> I've already this PR https://github.com/boostorg/thread/pull/213.
>
> Vicente
>
>
Boost.DateTime, Boost.Format, Boost.Uuid, and (hopefully soon)
Boost.ProgramOptions use Travis CI, Appveyor, codecov.io, and Coverity Scan.

Here's a pull request with these bits added and instructions; you could use
something similar to bootstrap thread:
https://github.com/boostorg/program_options/pull/47

The only complaint is that since we all have different repositories, I now
have multiple copies of my generic "ci/" script directory floating around.

Here's a good example of this integration at work:
https://github.com/boostorg/format/pull/53

Repositories with builds that take less than 50 minutes per build job can
use Travis CI.
If your build is longer, like Boost.Spirit is, then you may need another
solution like CircleCI.

In any case whatever you choose, it's good to see the project as a whole
moving towards more modern delivery processes and submitter self-service.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 07/03/2018 à 19:41, Vicente J. Botet Escriba via Boost a écrit :

> Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :
>> Vicente J. Botet Escriba Via Boost wrote:
>>> Hi, recently I heard of CircleCI (https://circleci.com/) and it
>>> seems much faster than Travis.
>>>
>>>
>>> Is someone using it? What is your feedback?
>>>
>>> If the feedback is positive, could someone authorize CircleCI to
>>> access boostorg?
>>
>> We're using it at Boost.Geometry since Jun 2015. The reason is we
>> have many quite extensive tests which fail at Travis due to time and
>> memory constraints.
> Adam, what I must do for Boost.Thread?
> I've already this PR https://github.com/boostorg/thread/pull/213.
Sorry for the noise.

I had the right to enable the build. I had just to do it. It is working now.

https://circleci.com/gh/boostorg/workflows/thread

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: About authorizing CircleCI

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vicente J. Botet Escriba wrote:

> Le 06/03/2018 à 22:05, Adam Wulkiewicz via Boost a écrit :
>> Vicente J. Botet Escriba Via Boost wrote:
>>> Hi, recently I heard of CircleCI (https://circleci.com/) and it
>>> seems much faster than Travis.
>>>
>>>
>>> Is someone using it? What is your feedback?
>>>
>>> If the feedback is positive, could someone authorize CircleCI to
>>> access boostorg?
>>
>> We're using it at Boost.Geometry since Jun 2015. The reason is we
>> have many quite extensive tests which fail at Travis due to time and
>> memory constraints.
> Adam, what I must do for Boost.Thread?
> I've already this PR https://github.com/boostorg/thread/pull/213.

We have circle.yml script in the main repo dir defining what needs to be
done. AFAIR it was based on some older Antony Polukhin's TravisCI script
for testing Boost.Variant with Coveralls support. The script is more
complex than the example ones because everything is done by hand, the
tests are divided into 2 parallel builds run on separate containers,
then coverage results are gathered on one machine, combined into one
file and sent to Coveralls.

So if you'd like to use this script you'd have to modify it. There are
comments describing what's happening exactly so you shouldn't have
problems with it. If you decided to use it and run into some problems
contact me.

Plus AFAIR you have to log in at CircleCI with GitHub credentials to
configure some things and then allow CircleCI to have access to your repo.

Adam

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost