[thanksgiving]

> 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".

[tedmiston]

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.

[thanksgiving]

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?

[tedmiston]

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.

https://circleci.com/docs/2.0/local-jobs/

[vidarh]

> 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.