​
Build context

When Aptible builds your Docker image using Dockerfile Deploy, the build context contains the git repository you pushed and a .aptible.env file injected by Aptible at the root of your repository. Here are a few caveats you should be mindful of:
  • Git clone is a shallow clone
    • When Aptible ships your git repository to a build instance, it uses a git shallow clone.
    • This has no impact on the code being cloned, but you should be mindful that using e.g. git log within your container will yield a single commit: the one you deployed from.
  • File timestamps are all set to January 1st, 2000
    • Git does not preserve timestamps on files. This means that when Aptible clones a git repository, the timestamps on your files represent when the files were cloned, as opposed to when you last modified them.
    • However, Docker caching relies on timestamps (i.e., a different timestamp will break the Docker build cache), so timestamps that reflect the clone time would break Docker caching.
    • To optimize your build times, Aptible sets all the timestamps on all files in your repository to an arbitrary timestamp: January 1st, 2000, at 00:00 UTC.
  • .dockerignore is not used
    • The .dockerignore file is read by the Docker CLI client, not by the Docker server.
    • However, Aptible does not use the Docker CLI client and does not currently use the .dockerignore file.

​
Multi-stage builds

Although Aptible supports multi-stage builds, there are a few points to keep in mind:
  • You cannot specify a target stage to be built within Aptible. This means the final stage is always used as the target.
  • Aptible always builds all stages regardless of dependencies or lack thereof in the final stage.