We’d like your feedback!


#1

Please create your feedback posts here: https://discuss.circleci.com/c/circleci-2-0/feedback

CircleCI 2.0 is a highly customizable, powerful platform that includes first-class container support. It will help teams of all sizes realize even more of the benefits CI and CD bring. The new and expanded CircleCI 2.0 functionalities empower teams to do their best work. We would like to hear your feedback for this new platform.

  1. What do you enjoy or find painful?

  2. What would you like to see added or changed?

  3. Anything else you might want to say (the previous two questions are just to get your thoughts going).

If you agree with others’ feedback, feel free to leave a comment, but also be sure to like their post (using the :heart:️ icon). The latter approach makes it easier for us to see the demand of issues.


Timeline for CircleCI 2.0?
#3

#4

#5

Hey, is there a way to use docker within a build step?


#6

Not yet, we are working on implementing this soon and will have a getting started guide once it is available.

If you have any non-docker projects that you want to try out let us know and we will add them!


#7

A slightly painful thing I’m finding right now is that we have quite a complicated circle.yml file and it’s not 100% clear how the syntax changes from version 1 to version 2.

It’d be great to get an explicit comparison of “old world” and “new world” approach for implementing each config setting (i.e. machine:host, machine:environment) or even better, a tool which helps you build a V2 setup from a V1 circle.yml file (assuming you wanted the CircleCI-inferred build process).

I love the idea of independent tasks and resource customisation but right now it looks like I need to totally rewrite our circle.yml file to take advantage of these features?


#8

Thanks for the feedback! The new circle.yml syntax is still in an experimental phase and is subject to change. Once we have a finalized version in place we will create a nice doc with the appropriate mappings. Ideally there will not be that many major changes in how the config is created.

In the meantime, I would be glad to work with you on this. Could you DM me with your existing circle.yml? If this is not sensitive, it would be even better if you shared it in the support sub-section so we can work on it in public and share with other folks who might be feeling the same pain. :slight_smile:


#9

Cheers for the prompt response - of course! Have DM’d you a cut-down version of our circle.yml and more than happy to share the results if/when we get it working with V2.


#10

Thanks for the quick reply, v2 looks awesome so far, but we don’t really have none docker projects anymore :frowning:


#11

Thanks for helping out @levlaz

Hi @johanneswuerbach,

You request and CircleCI delivers :slight_smile:

We just finished adding support for additional docker functionality.

Please reach out to your CSM who helped you onboard and we will send you detailed instructions to get you started.


#12

why is the “workDir” statement being used with ‘’?
I try to use env variables and i get:
path ‘/home/ubuntu/"${CIRCLE_PROJECT_REPONAME}"’ not found
I also tried with $CIRCLE_PROJECT_REPONAME


#13

What do you enjoy or find painful?

I’m finding creating a proper 2.0 circle.yml file painful because there is not enough information available about what options the file can include. For example, can we start containers with --volumes-from option or is that something that is handled by the Pod automatically? Speaking of the Pod, it’d be great to have some details on what it is, how it works (generally). Actually, a brief overview of how Circle 2.0 works would probably make creating the new circle.yml files much easier.

What would you like to see added or changed?

More detailed documentation.

Anything else you might want to say (the previous two questions are just to get your thoughts going).

The new circle.yml format is too verbose. With Circle 1.0 running a command required just a single line. Now its a minimum of three lines per command–and the first two lines are the same for all commands (pretty much)

I do realize this is beta and so the docs aren’t ready yet. I get it, hell we’ve all been there, done that :wink:


#14

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.


#15

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!

Thanks!


#17

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!


#18

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.


#19

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!


#20

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
#22

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.


#23

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”