The only thing I changed in my App Spec file is database username. Yet it triggered full rebuild of the Docker, which takes around 10 minutes for 1 service + 10 minutes for a job (both using the same Dockerfile).

There are two issues here:

Issue 1. Docker build cache is not used.

Issue 2. Docker build result is not shared between the job and the service.

This makes me wait for 20 minutes every time I experiment with the App spec, even though there is nothing that would indicate the need to rebuild from scratch:

  • no build time args changes
  • no Dockerfile changes

Is this expected behavior?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers

From your Dockerfile, if you append lines to your Dockerfile, or change the code being built, there’s only one line that could be cached:

RUN mkdir /code
After that, you perform a:

COPY . /code
Since you have changed your Dockerfile, the contents of . have changed (the Dockerfile is part of .) and therefore the COPY needs to be performed again, generating a new layer. Once you generate a new layer, every following layer no longer has a cache and needs to be rebuild.

To improve caching, consider placing the lines that change less towards the top of your Dockerfile. That would leave the COPY . /code line at the very end of the file since it will change almost every time.

  • Thanks @pistle2020! Please check: I have many instructions before the first COPY happens. The very beginning of my Dockerfile is as follows, am I doing it wrong and causing building from scratch all the times? If so, how could I improve?


    FROM php:7.4.11-fpm
    
    # procps and htop is needed for development only
    RUN apt-get update \
      && apt-get install -y \
        nano \
        bash-completion \
        zsh \
        zsh-syntax-highlighting \
        procps \
        htop \
        zip \
        libpng-dev \
        unzip \
        lsb-release \
        wget \
        gnupg2 \
        libpq-dev \
        libtidy-dev \
        libyaml-dev \
        lsof \
        autossh \
        locales \
        webp \
        jpegoptim \
        optipng \
      && usermod -s /usr/bin/zsh $(whoami) \
      && echo "source /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh" >> ~/.zshrc
      # && sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
    
    # Planned supported languages: Spanish, Portuguese, French, Russian, Manadrin
    RUN echo "ru_RU.UTF-8 UTF-8" >> /etc/locale.gen \
        echo "fr_FR.UTF-8 UTF-8" >> /etc/locale.gen \
        echo "pt_BR.UTF-8 UTF-8" >> /etc/locale.gen \
        echo "es_ES.UTF-8 UTF-8" >> /etc/locale.gen \
        echo "zh_CN.UTF-8 UTF-8" >> /etc/locale.gen \
        && locale-gen \
        && echo "LANG=\"en_US.UTF-8\"" >> /etc/default/locale \
        && echo "export LANG=en_US.UTF-8" >> ~/.zshrc
    
    
    RUN apt-get update \
      && apt-get install -y python3-pip \
      && pip3 install supervisor
    
    RUN apt-get install -y zlib1g-dev libicu-dev g++ \
      && docker-php-ext-configure intl \
      && docker-php-ext-install intl
    
    RUN docker-php-ext-install pdo_pgsql
    
    RUN docker-php-ext-install tidy \
        && docker-php-ext-enable tidy
    
    RUN docker-php-ext-install gd \
        && docker-php-ext-enable gd
    
    RUN pecl install redis-5.3.1 \
        && docker-php-ext-enable redis
    
    RUN pecl install yaml \
        && echo "extension=yaml.so" > /usr/local/etc/php/conf.d/ext-yaml.ini \
        && docker-php-ext-enable yaml
    
    RUN docker-php-ext-install pcntl \
        && docker-php-ext-enable pcntl
    
    RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
    RUN composer --version
    

@ReWild 👋

Thanks for surfacing this — it’s not intended behavior. This is related to the job component specifically, where we were not excluding some of the non-build context from the reuse keys. We’ve deployed a fix for this, and is working as expected now. Let us know if you hit any more problems or if it’s not completely resolved for you.

Submit an Answer