Generating compact Dockerfiles, different layers for CI testing + deployment

[telegott]

From a Docker best practices standpoint, if I'm correct it is common to create a single layer for each logical step and each docker command such as RUN creates a new layer.
For setting up an R docker container, these logical steps might be installing all R packages or the Linux system libraries + the packages in one go/layer.
For example, a Dockerfile generated by golem looks something like

FROM rocker/r-ver:4.1.2
RUN apt-get update && apt-get install -y  git-core libcurl4-openssl-dev libgit2-dev libicu-dev libssl-dev libxml2-dev make pandoc pandoc-citeproc && rm -rf /var/lib/apt/lists/*
RUN echo "options(repos = c(CRAN = 'https://cran.rstudio.com/'), download.file.method = 'libcurl', Ncpus = 4)" >> /usr/local/lib/R/etc/Rprofile.site
RUN R -e 'install.packages("remotes")'
RUN Rscript -e 'remotes::install_version("processx",upgrade="never", version = "3.5.2")'
RUN Rscript -e 'remotes::install_version("testthat",upgrade="never", version = "3.1.0")'
RUN Rscript -e 'remotes::install_version("shiny",upgrade="never", version = "1.7.1")'

This could be condensed into a single layer like

FROM rocker/r-ver:4.1.2
RUN set -xe \
    && apt-get update \
    && apt-get install -y \
        git-core \
        libcurl4-openssl-dev \
        libgit2-dev \
        libicu-dev \
        libssl-dev \
        libxml2-dev \
        make \
        pandoc \
        pandoc-citeproc \
    && rm -rf /var/lib/apt/lists/* \
    && echo "options(repos = c(CRAN = 'https://cran.rstudio.com/'), download.file.method = 'libcurl', Ncpus = 4)" >> /usr/local/lib/R/etc/Rprofile.site \
    && R -e 'install.packages("remotes")' \
    && Rscript -e 'remotes::install_version("processx",upgrade="never", version = "3.5.2")' \
    && Rscript -e 'remotes::install_version("testthat",upgrade="never", version = "3.1.0")' \
    && Rscript -e 'remotes::install_version("shiny",upgrade="never", version = "1.7.1")' \
    && Rscript -e 'remotes::install_version("config",upgrade="never", version = "0.3.1")' \
    && Rscript -e 'remotes::install_version("spelling",upgrade="never", version = "2.2")' \
    && Rscript -e 'remotes::install_version("golem",upgrade="never", version = "0.3.1")'

I agree that for debugging purposes, it might be helpful to have lots of different layers if there is an error in a single step, but later on if a package version changes it's not clear at which position in the steps it was, so a "clear" rebuild wouldn't be bad either.
It could also be an option to the function that allows to create a "flat" or a "compressed" version.

Also for example when using Jenkins it's possible to use a Dockerfile to set up the environment for testing before deploying an app. The layers would be very similar, so there could be the generated base layer that sets of the environment, a deploy layer that only adds the CMD step ontop and a test layer that has steps that might be necessary in addition for testing on Jenkins on top of base. Are there any plans in such a direction?