我在Dockerfile中有一些RUN命令,每次构建Docker映像时,我都希望使用-no-cache运行这些命令。

我理解docker构建——无缓存将禁用整个Dockerfile的缓存。

是否可以为特定的RUN命令禁用缓存?


当前回答

我相信这比@steve的回答略有改进:

RUN git clone https://sdk.ghwl;erjnv;wekrv;qlk@gitlab.com/your_name/your_repository.git

WORKDIR your_repository

# Calls for a random number to break the cahing of the git clone
# (https://stackoverflow.com/questions/35134713/disable-cache-for-specific-run-commands/58801213#58801213)
ADD "https://www.random.org/cgi-bin/randbyte?nbytes=10&format=h" skipcache
RUN git pull

这使用了git克隆的Docker缓存,但随后运行了存储库的非缓存更新。

它似乎可以工作,而且速度更快-但非常感谢@steve提供了基本原则。

其他回答

如果你的目标是包括来自Github(或类似)的最新代码,你可以使用Github API(或等效)来获取有关最新提交的信息,使用ADD命令。 docker build将始终从ADD命令中获取URL,如果响应与上次docker build运行时接收到的响应不同,它将不使用后续的缓存层。

eg.

ADD "https://api.github.com/repos/username/repo_name/commits?per_page=1" latest_commit
RUN curl -sLO "https://github.com/username/repo_name/archive/main.zip" && unzip main.zip

该功能是一周前添加的。

ARG FOO=bar

FROM something
RUN echo "this won't be affected if the value of FOO changes"
ARG FOO
RUN echo "this step will be executed again if the value of FOO changes"

FROM something-else
RUN echo "this won't be affected because this stage doesn't use the FOO build-arg"

https://github.com/moby/moby/issues/1996#issuecomment-550020843

不是直接的,但是你可以把你的Dockerfile分成几个部分,构建一个镜像,然后从这个镜像开始到下一个Dockerfile,然后构建这个镜像,有缓存或者没有缓存

我相信这比@steve的回答略有改进:

RUN git clone https://sdk.ghwl;erjnv;wekrv;qlk@gitlab.com/your_name/your_repository.git

WORKDIR your_repository

# Calls for a random number to break the cahing of the git clone
# (https://stackoverflow.com/questions/35134713/disable-cache-for-specific-run-commands/58801213#58801213)
ADD "https://www.random.org/cgi-bin/randbyte?nbytes=10&format=h" skipcache
RUN git pull

这使用了git克隆的Docker缓存,但随后运行了存储库的非缓存更新。

它似乎可以工作,而且速度更快-但非常感谢@steve提供了基本原则。

在想要禁用缓存的区域之前,总是可以插入一些无意义且运行成本低的命令。

正如在本期评论中提出的,可以添加一个构建参数块(名称可以是任意的):

ARG CACHEBUST=1 

并在每次运行时通过添加——build-arg CACHEBUST=$(date +%s)作为docker构建参数来修改它的值(value也可以是任意的,这里是current datetime,以确保它在不同运行时的唯一性)。

当然,这也会禁用所有后续块的缓存,因为中间映像的哈希和将是不同的,这使得真正的选择性缓存禁用成为一个不平凡的问题,考虑到docker当前的工作方式。