ubuntu-14.04-XXL-upstart-1189-5614f37 pulls every time


I’m trying to transition from 1.0 to 2.0 and I’m having a terrible time (every aspect of 2.0 feels worse than 1.0 to me so far). I don’t think it will be useful to have a single topic for every one of the issues I’m coming across, so I’ll focus on this one here.

Every CircleCI 2.0 build spends 8+ minutes just retrieving the docker image. This is the image that the config-translation tool set me up with, so it’s alarming to me that it’s such a bad experience.

  - image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
    command: /sbin/init

Can this be resolved on your end?
Should the config-translation tool be suggesting a different image that is available on the host?

Upgrading to 2.0 - Config-translation error & deprecated base image!

That does sound too long. Where are you fetching it from, and how big is it? I’m pulling 13 images, totalling over 900M, from two different DCs outside of the CircleCI firewall, neither of which are optimised for latency, in 57 seconds.


Can you re-submit those themes as actionable items of feedback? There’s also a feature request widget on the main site, if you didn’t already know. (Not an employee, by the way - just a satisfied free-tier user on 2.0).


I don’t know if this will answer your question, but these are all the details I know…

I’m using exactly what config-translation provided to me in my config.yml file:

  - image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
    command: /sbin/init

The log output in CircleCI’s web dashboard is:

Build-agent version 0.0.4718-e506b53 (2018-03-07T01:49:56+0000)
Starting container circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
  image cache not found on this host, downloading circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
ubuntu-14.04-XXL-upstart-1189-5614f37: Pulling from circleci/build-image

It runs that docker pull just about every build (I’ve seen a couple where it didn’t, perhaps because it re-used the host). I’m surprised that the default CircleCI images aren’t cached on the host already.


Would you link to the location of your specific image in Docker Hub? For some reason the site is not letting me browse the images you’ve linked to. I want to see how large the image is.


I think the image in question is https://hub.docker.com/r/circleci/build-image
If you view the tags page, you can search for ubuntu-14.04-XXL-upstart-1189-5614f37

:thinking: It’s 7gb… I might have a better experience pulling the stock Ubuntu image & installing everything I need. :confounded:

(This is a good example of the terrible experience I’m having. They announce that 1.0 is going away, and provide me with a configuration translation tool. They are pretty clear about it not producing a production-ready configuration, but the first experience I have with 2.0 is an 8+ minute wait for an image that “mirrors the build environment we use on the 1.0 platform” and produces errors while installing the same set of gems that install fine in 1.0. It has been an agonizing 4.5 hours so far.)


Yeah, for some reason Docker Hub is not responding on my connection atm. No matter, you’ve answered my question - 7G! I don’t know what this image does, but I hope it brings you your carpet slippers and makes you a cup of tea :tea:

(One of my images is ~550M, due to some unusual requirements, but all others are <100M. Docker is all about keeping images small).

I mean this respectfully, but the platform is what it is. I’ve been lurking and helping here for a while, and the thing I notice most of all is that a positive frame of mind really helps. I’ve had a couple of hiccups too, but if you look for problems, then problems will find you :smile:. CI is not an easy thing to get right, even with providers like Circle.

Tbh, I prefer that. It makes for a more stable experience - the Circle images are automatically rebuilt based on latest minor updates (e.g. Python). I’ve seen folks with breakages. I like to control all this myself.


@JamesChevalierCMI Yes that image is attempting to mimic the environment in CircleCI 1.0, which is huge.

The idea is that this image should get you up and running almost immediately with passing builds. Then, you can start deciding which images/tools would be most beneficial to you to optimize the build and reduce build times.


That makes sense, but it didn’t work. This image doesn’t mimic the CircleCI 1.0 environment. I’m not sure I can fault anyone for that, though - I can’t imagine how much effort it is to get to that point.

I think I’m left with this piece of feedback:
Make this image cached on the host server.

My reasoning here is that it would make the experience for people migrating from 1.0 to 2.0 much nicer. It would have trimmed my debugging time down by 8+ minutes on every attempt, ultimately saving me about a full day of effort.
If you’re going to attempt to help us migrate in this manner, go all the way. If you’re not going to go all the way in assisting with the migration, then you can probably save yourself a bunch of time and not attempt to provide this step of the process. I may have been better off if your config-translation tool left me with a standard ubuntu:14.04 image and told me to install the software I required.


It does i terms of having installed what 1.0 has installed. It doesn’t (and can’t unfortunately) run the Inference commands that 1.0 would have.

Docker images are cached somewhat. Your build shouldn’t need to redownload the image when it runs on a VM that has already downloaded it. We have a very large fleet to support the millions of builds per month that we do. Whenever your build kicks up on a VM it hasn’t run on before, the image will be downloaded.

I’ll be frank, there might be a higher cache miss in this scenario due to the sheer size of this image.

I hear your feedback regarding the config-translation tool. Will share with the team.


Using the dockerfile wizard (https://circleci.com/docs/2.0/custom-images/#circleci-dockerfile-wizard) it’s not too hard to build your own image. Building one takes about 50 minutes per attempt, but once done it pulls in a minute for me. Which is still slower than it used to be overall when using workflows (each phase pull the image again) but it’s a lot faster than pulling the full 1.0 image.


This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.