We’d like your feedback!


Hi @lots0logs

Thank you for providing valuable feedback.

Pod : A “pod” is a group of combined containers that is treated as a single container.

We are adding more documentation to help simplify writing config’s / circlece.yml. Coming soon :slight_smile:

We are actively working on reducing verbosity of our circle.yml. Be rest assured, our final version of config will not be verbose.

Your feedback is valuable and thank you for helping out with 2.0 Closed Beta.


We aren’t supporting all of the environment variables from the current version of CircleCI. However, this is on our list and we will have it out as soon as we can!

Right now, we are only supporting absolute paths for workDir IE /home/ubuntu/project_name. I will pass your request to support environment variables in the workDir along to our engineers!



What do you enjoy or find painful?

I like the additional flexibility the new circle.yml gives. Im building a Rails app and running Phantomjs automation tests and would like to create a base docker image that has all the setup I need already done. The docker support in CircleCI 2.0 should allow even faster builds than I get with the current release.

Documentation as others have pointed out. Would be nice to know what environment variables in the current release will work in the 2.0 beta (eg, CIRCLE_ARTIFACTS…etc).

What would you like to see added or changed?

Here’s a few questions I hope you can answer.

  1. Will the code coverage gem SimpleCov work with CircleCI 2.0? Im currently using it in CircleCI 1.0.

  2. Is circleci/minitest-ci supported with CircleCI 2.0?

  3. Are there any plans for automatic test balancing based on runtimes/file size or do we just manually split the tests among containers as the examples show?

  4. My circle.yml has two shell steps (one for specs and one for phantoms tests), if the spec shell step fails then the next shell step for the phantomjs tests is skipped and goes right to artifact upload. Is this
    how shell steps are expected to work when a failure occurs?

I can provide my circle.yml if needed.
Good job, look forward to more updates from this beta!


With regards to the config format being too verbose: I would love to see special branch config flag/option come back.

In the deployment examples section you have to use a bash command to conditionally execute a deployment on a branch, where as in 1.0 there was the handy “branch” config key.


Hi guys, here’s some feedback:

What we’ve liked so far:

  • Increased speed.
  • Docker image cache (it would be even better if the cache could be global and shared between all of your machines).
  • Low level and highly customisable build steps (e.g.: custom cache handling).

What we’re missing:

  • docker-compose and docker-compose build support, we’d like to use our existing configuration to bring up containers to reduce the possibility of errors and also we’re adding some packages only in development/test using a Dockerfile that extends our production images, so right now we would have to push this extended docker image in order to use it on circle 2.0 which is not ideal as it would be a pain and error prone to keep it in sync.
  • AWS credentials integration (the config specified in the project that works on the 1.0 infrastructure is simply ignored AFAIK).
  • The ability to run commands outside of docker (this is useful to have a common build script that uses docker-compose under the hood, but can be run anywhere).
  • The ability to specify on which container every command specified in the build steps should be run instead of having everything run on the first container in the list, we don’t like to bake everything into a single container, we’d much rather have single purpose container, this also allows to use different software version in a very easy way.

Anyway, we think that this is a very interesting improvement over the current version, thank you for all your work!


Thank you everyone for the detailed feedback.

@andreausu, we have added support for docker-compose.

In the next few days, we will enable Docker build functionality for all our beta customers.

Frequently Asked Questions

It looks like the CIRCLE_PROJECT_REPONAME env var no longer exists in 2.0. This was very useful for generalizing certain steps of a build/deploy (for example, I can no longer do this: docker build -t quay.io/myapp/$CIRCLE_PROJECT_REPONAME:$CIRCLE_SHA1). Any chance we can get that variable back?

The CIRCLE_BUILD_URL env var also seems to have disappeared, while less important, that one was useful in chat messages linking directly to the build.


What we are missing:

  • SSH into build feature (it’s very useful when debugging why build fails)
  • Pulling private images and running commands against them (probably requires registry / credentials integration). For CircleCI 1.0 we do it through environment variables but it would be nice if we could do it “natively”



Would be great to have $CIRCLE_PROJECT_USERNAME and $CIRCLE_PROJECT_REPONAME environment variables back.

  1. Yes, it should. Please let us know in the Support subcategory of Discuss if it isn’t working as expected.

  2. Same as 1.

  3. Our engineers are talking about this, but there are no concrete plans yet. For now, you’re best off splitting tests as in the examples.

  4. Yes, this is expected behavior and should mirror behavior in CircleCi 1.0.


Re: SSH - we feel the pain of this too. It’s a high priority to get this into 2.0

Re: private images - there are security concerns with doing this for executor: docker (in short, it’s hard if not impossible to secure a cached private image against other users on that machine). I believe this is one motivation for making executor: machine. Private images are on our roadmap.


What’s the plan for XCode?


I setup CircleCI 2.0 for our go project that should result in a docker image. On the positive side: the implementation is really smooth: I was able to reduce our build time from about 5min → 50seconds!

Which is awesome! :tada:

Mostly through the use of excutionType: docker but there have been a few things that have not been as smooth as they could have been:

  1. If you use a custom docker image it needs to come with a set of tools. without them the build process doesn’t work: i.e. to checkout you need git & openssh & bash installed. (Figuring this out has been quite a bother tbh.)

  2. Under “containerInfo” it is possible to specify an array: What is the image used to execute the shell scripts? I would have assumed a “docker-compose”-like specification:

          image: golang:1.6.2
          image: mongo:3.2
  3. Building on 2: We run the code in a docker container after publishing. This could be the same docker container that is used to test the code. It would be awesome if I could specify:

          build: .

    and then have a buildstep that looks like:

            - type: docker-push
              image: _
              name: myproject:build_${BUILD_ID}
              target: hub.docker.com
              credentials: "Bearer: abcdefghijklmnopqrstuvwyz012345"

    (Which is not run in the container - obviously)

    This would remove the main 3 problems with the current project (and make my life :sunny:) :

    1. I currently need to manually trigger caching even though my Dockerfile has all mechanisms set up for it.

    2. I can use ON_BUILD operations of the Dockerfiles and don’t need to write a separate script file for circleCI that does exactly the same thing as I do in the ON_BUILD steps.

    3. With directly pushing the build I safe the time later when deploying the image.

  4. The deployment configuration has become less clear now. I am able to choose with a script which branches should be deployed (which is cool) but I am not seeing the “deployment” step run after every process?! Why not? Related: why is “stages” not simply an array that is freely specifiable?

  5. Rebuild without cache feels like it should be pulling the image again. Or - at the very least - check if the sha of the image on docker-hub has changed and then pull it. (Adding a sha hash to the image tag helps around this issue)

  6. The CIRCLE_NODE_INDEX should be available in the cache sections. This way it is possible to run two different parallel processes in two different parallel tasks and cache the results for each.

Docker builds for docker engine
Docker builds for docker engine

My initial honest feedback is I would have preferred a “CircleCI 1.1” that did what the production CircleCI does but with fully-working Docker support (fixing “docker exec” and being able to cache images, specifically). We have nearly all our projects building in CircleCI now, and I can’t put a high priority on going through all of them to convert to a new format.


A post was split to a new topic: How to view test reports?


XCode is not the current priority on 2.0, but some of our engineers are talking about how to make a 2.0 equivalent. Maintenance and support for XCode on 1.0 will continue with XCode version updates and bugfixes until we have a stable alternative.

This would have been nice for us too, but I believe it wasn’t technically feasible. To respond to your examples of fully working Docker features in 1.0:

  • A fully functional docker exec on our 1.0 SaaS product would compromise customer security with 1.0. Some of our enterprise customers have a more full-featured docker exec. This is secure for them because they’re running an instance of CircleCI inside an environment with only trusted users. (This is still an option for your team: to move over to our enterprise product).
  • Being able to cache Docker images on 1.0: Docker changed this behavior in 1.10. There’s more about that in this docker issue. For CircleCI, this new architecture was the minimum that we could do to get Docker caching working similar to how it works in a local environment.


Thank you for the thorough feedback! This is a really meaty post, so I’ll reply piece by piece.

This has burned others too. I’m making sure our product/engineering team sees this. Are you sure about needing to have bash installed? I believe some users have reported using Alpine images with success.

Have you tried using the machine executor? It offers more full-featured Docker support and might better address your needs.

The image used to execute shell scripts is image 0 in that image array. This is mentioned briefly in the “Pod (build images)” section of the getting started guide. Should we make this more obvious?

This sounds like a bug. Can you create a separate post for this in the 2.0 support subcategory? We’ll likely need to see some example build links to debug it.

“stages” is a hashmap and not an array because we intend to expand this section with other types of sections with different semantics. The “deployment” section, for instance, should only run on a successful build and in only one Docker container.

The short answer to this is that we recommend against using mutable tags. This includes latest, but anything else that might change meaning over time. I’m going to write up another post detailing why and link back here when I’m done.

This is interesting feedback. The potential use cases for this are clear to me. I’ve made an internal feature request for this.


Thank you for your thorough reply!

Are you sure about needing to have bash installed?

Yes. I distinctly remembered this being the case.

have you tried using the machine executor

I know it possible using the machine executor but there are two reason why I wouldn’t want to go down that road:

  1. The executor spins up a new vm instead of launching a docker image which is slower

  2. (by far more important) If I use the cache to build image I can only store the final images (no build steps in-between). It is those build steps in-between that I am interested in having for the next build as they contain the downloaded dependencies and such. This would improve my caching setup and overall experience with circleci massively!

Should we make this more obvious?

It would have definitely helped me if this was more clear. Rather than adding documentation though I would be all for changing it into a map/object/dictionary rather than an array. This way other people (that didn’t read the docs) would also understand this immediately. Good names, good life :wink:

Can you create a separate post for this in the 2.0 support subcategory?

I can not promise you but I will try to spend some time to properly summarize this issue.

“stages” is a hashmap and not an array because we intend to expand this section with other types of sections with different semantics.

In other sections of the yaml files you specify different “types” of steps. It would seem only natural and consistent to me if each step had its own type… but maybe that i just me.

 - type: deployment
     - ....

The short answer to this is that we recommend against using mutable tags.

I understand the reasoning of this and tbh. I wasn’t quite sure if I should bring it up. In my case though I was developing and publishing the base image myself and tagging the image felt like a nuisance.


3 posts were split to a new topic: Skip a step on cache-restore

Skip a step on cache-restore

Alpine images do not have bash but you can specify the shell as being /bin/sh without any issues.