> This doesn't seem like glowing praise to me? If I'm paying 50$ per month for a container, I want it to be faster than a laptop...
Maybe I am doing it wrong but do people create and destroy a container thingy every time they run a test?
I agree with you though. I am no expert by any means I'd expect Circle CI to be faster than a Macbook at building things like Google Chrome from scratch. But if the macbook already has a head start, then coming a close second is acceptable I suppose?
To be honest, I have no idea what I am talking about and hoping to learn more. My experience with CI is mostly with hobby projects with Gitlab CI and Travis CI. I've only ever "used" Atlassian Bamboo at work if you can call me pushing code to trunk/origin "using Bamboo".
Yes, CircleCI creates a Docker container for every run. In the CircleCI 2.0 config style it is more explicit about this behavior (one specifies the Docker image they want to use) while in the 1.0 API, the config was more inferred / implicit. It can get more complicated than this, but at minimum every build on CircleCI is creating and destroying at least one container to run the unit test suite. It can do this pretty quickly though: a barebones Python repo (1 function, 22 parameterized unit tests) for me takes ~12 seconds from startup to teardown to displaying the completed build using 2.0 with virtual environment caching.
Sorry, I meant to ask about locally. I am still trying to figure out how to write code in docker. It is very confusing and send like too much work to do this locally.
I assume the disk is pretty much always the bottleneck? I mean even with system CTL, how much memory can a rest API flask web app take right?
I'm not sure how it worked prior to 2.0 or if it was possibly, but you can build locally in 2.0 ($ circleci build) which I think is just a thin wrapper around a docker build + docker run + run unit tests (or whatever you want).
That said, you don't have to use Docker and for a small project with no dependencies or no system level dependencies, I think it's overkill personally, so I'd just test outside of Docker or use the new base images from Circle.
> Maybe I am doing it wrong but do people create and destroy a container thingy every time they run a test?
I create and destroy a container every time I:
* Run a test
* Start a command line environment for debugging (Ruby mostly, so usually "pry" with all my apps libraries loaded)
* Build anything (e.g. update the installed gems via bundler for Ruby)
* Run any scripts that are part of the app.
It means I can be sure I always run things in precisely the environment the apps will run in, including the right interpreter or compiler, right dependencies etc. - nothing "leaks" from my laptop. Nothing "leaks" to my laptop. I can trivially test with multiple different interpreter/compilers etc. without convoluted "environment management" tools that tend to be language specific. Bugs in my script are also reasonably well contained (though I won't trust Docker for isolation as sole protection against hackers, I trust it for isolation against my own stupid mistakes most of the time).
Bind mounts of the source directory ensures I can do live reloading of code etc. when suitable, so I don't need to restart those containers all the time.
Typically starting the Docker container is one of the fastest parts of the above - often my makefile will not just start a Docker container, but for simplicity run the build whenever I do anything (like run the test suite) to make sure I run it in the newest version of the container, and thanks to extensive caching that too rarely adds more than a few seconds.
In a CI setup like CircleCI, though, the "cost" in time of this when building remotely is pulling the relevant source images from their registry, and the images can be fairly big, especially if you're not specifically going to some effort to keep it down in size.
On shippable, the same tests took 100 times longer to complete, if they finished at all.
And I'm typically not sitting there waiting for them to finish. All I care about is that they eventually do and the code deploys. Just don't take forever.
I also understand that the company is going to be serving many other customers at the same time.
And, no, the first server is free. The second server is $50.
- I'm from Shippable and we have many customers who've moved from CircleCI to us because of many reasons like better Docker support and the ability to create simple to complex pipelines.
- I'm not sure if you contacted us to improve build times but I'd love to jump on a call and discuss your experience. This is definitely not the typical feedback we get so would like to dig in deeper and improve our handling of your scenario. manisha@shippable.com
- the first build server on circleci is only free up to 1500 build mins per month.
~50$ a month buys you a dedicated server with a Quadcore Skylake (i7-6700).
The fastest Macbook available right now has about the same CPU power, and comes with less RAM. So no, the Macbook isn't faster than what you could get, but it makes sense if rented CI infrastructure isn't faster for that price.
Just want to point out that there's also the fact that if they want good unit economics, only a fraction of the $50 you pay the is going to paying for the hardware.
Maybe I am doing it wrong but do people create and destroy a container thingy every time they run a test?
I agree with you though. I am no expert by any means I'd expect Circle CI to be faster than a Macbook at building things like Google Chrome from scratch. But if the macbook already has a head start, then coming a close second is acceptable I suppose?
To be honest, I have no idea what I am talking about and hoping to learn more. My experience with CI is mostly with hobby projects with Gitlab CI and Travis CI. I've only ever "used" Atlassian Bamboo at work if you can call me pushing code to trunk/origin "using Bamboo".