About authorizing CircleCI
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
On Tue, Mar 6, 2018 at 11:40 AM, Vicente J. Botet Escriba via Boost < boost@lists.boost.org> 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
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 <boost@lists.boost.org <mailto:boost@lists.boost.org>> 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
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/
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
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
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
On 7 March 2018 at 06:42, Vicente J. Botet Escriba via Boost <boost@lists.boost.org> 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.
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
On Wed, Mar 7, 2018 at 1:41 PM, Vicente J. Botet Escriba via Boost < boost@lists.boost.org> 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
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
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
participants (6)
-
Adam Wulkiewicz -
Daniel James -
James E. King, III -
Niall Douglas -
Rene Rivera -
Vicente J. Botet Escriba