Workflow: Feature requests - our findings



I’ve just gotten done re-writing a bunch of our CircleCI 2.0 configs to Workflow orientation and just wanted to enumerate a few of the key “issues” that I’ve had.

  1. Missing INTEGER build number
    We used to depend on CIRCLE_BUILD_NUM to generate minor versions of our deployment, after all it’s easier to correlate an integer with a point in time rather than a GUID. Workaround: We echo the BUILD_NUM to a text file and persist_to_workspace.
  2. Inability to set job priority
    We have 3 key steps – lint, test, build – the test takes longer than lint and build, so it would be nice to make sure it’s always started first rather than backing up behind lint or build. Workaround: Set an explicit dependency to force serialization.
  3. Estimate runtime is inaccurate
    Since we now have lots of build steps in the estimated runtime for any step appears to be the average of all of the steps, rather than taking into account the workflow ID. e.g. “npm_install” takes 30seconds, but “docker_build” takes 5 minutes – the estimate for docker_build is 35 seconds. Workaround: None
  4. Workflow page is frequently not refreshed
    It’s not uncommon to visit the workflow page to have it not reflect the current state of the workflows, it appears to be delayed. Workaround: Hard reload the page
  5. Workflow page defaults to empty
    It’s nice to have the build page full of builds and then filter by repo, having the “Builds” and “Workflow” tabs operate differently is a pain when you have lots of projects going.
  6. circleci/docker-aws image
    In the final stages of our build, we need to generate a docker image for deployment. It would be nice to have a standard docker image to use (potentially getting a caching performance boost) with AWS installed so that we can build and push to AWS ECR without having to install the tooling necessary everytime.

Some of these are repeats from past forum posts but thought I would share my summary. Overall was able to reduce our build times from 11 minutes to 3 minutes on average, though deployment builds still take 9 minutes. It also provides a great framework for growing out what we’re doing.


Wow great feedback and very in-depth. I wanted to say that I really appreciate you taking the time to write this. I’m going to share this with our engineerings and PMs to get your feedback more exposure internally.

Thank you.

Btw, for point 6, you might want to look into the CI Builds: AWS image. I maintain it as a 2nd-party suite of Docker images for CI environments. Maybe it’ll have what you need. Here’s the Docker Hub link for the image and the GitHub link for the source code.


Thanks for reading and passing around :grinning:

Your reference to your Docker Hub page is great. The one thing I would encourage you and CircleCI to do is provide links to the Dockerfile for the images. I’m “happy” to trust circleci/node to provide “trustworthy” docker images, but I have a bit of paranoia when it comes to “unknown” sources which also don’t provide a Dockerfile to inspect to know the bundle contents…


Hi there @koblas, we already do that in our Docker Hub staging environment, and we will be making the same change to shortly!


The CircleCI COnvenience Images Dockerfiles can be found here btw: