Does hub.docker.com use “–no-cache” for automated builds?

I am analysing some slightly strange behaviour in our automated build processes, which lead me to ask:

Does hub.docker.com use the --no-cache option when performing automated builds?

  • socket.error: timed out (Celery & RabbitMQ running in docker containers)
  • How to open/run YML compose file?
  • Docker Add/Copy subdirectory separately
  • Jenkins SCM Sync Configuration Plugin In Docker Won't Talk to Github
  • Renaming a file on Docker build does not persist
  • nginx as load balancer: upstream with path
  • psycopg2 installation for python:2.7-alpine in Docker
  • Can't deploy artifact to KIE-server via Drools workbench because of “ConversationId not valid - missing releaseId”
  • Running docker without sudo on Ubuntu 14.04 [closed]
  • Docker - Backup Containers in /var/lib/docker/vfs/dir
  • service tomcat7 start fails, but the process exists and tomcat is running
  • getting java.net.UnknownHostException while running GOCD docker container in QNAP
  • 2 Solutions collect form web for “Does hub.docker.com use “–no-cache” for automated builds?”

    Yes. The build process is currently:

    1. git clone --recursive --depth 1 -b branch $URL
    2. Extract Readme and Dockerfile
    3. docker build -t tagname --nocache
    4. Tar and upload the build context to S3 bucket
    5. Push image (with all layers) to Registry
    6. Worker or Builder cleans up build residue (mounted volumes, etc)

    Unfortunately, this was not the case for me. I had to end up rebuilding the image with the –no-cache flag. Then push the image up to docker hub.
    Admittedly the dockerfile used was not with best practice as it involved a “git pull”. Oh well!

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.