Stale cache reported by podman build despite changed external package sources

Understanding Podman Cache Invalidation

Podman does not offer a built-in mechanism to automatically detect changes in external repository metadata or remote file contents. The build cache key for a RUN instruction is based solely on the text of the command itself. If the command string (e.g., RUN apt-get update && apt-get install -y curl) remains unchanged, Podman assumes the result is identical and reports "Using cache," regardless of whether the remote packages have been updated.

Cache-Busting Strategies

Because Podman cannot monitor external state, you must explicitly signal the build engine to invalidate the cache for specific layers.

1. Using Build Arguments (Recommended)

The most effective way to force a rebuild of a specific step is to introduce an ARG immediately before the RUN command. Changing the value of this argument invalidates the cache for that ARG line and every subsequent instruction in the Dockerfile.

# Dockerfile example
FROM fedora:latest
# This ARG acts as a cache buster
ARG CACHE_DATE=2026-10-10
RUN dnf update -y && dnf install -y httpd

To trigger a refresh, pass a new value during the build:

podman build --build-arg CACHE_DATE=$(date +%Y-%m-%d) -t my-app .

2. The --no-cache Flag

If you need to ensure the entire image is fresh, use the --no-cache flag. This is a heavy-handed approach that ignores all cached layers, significantly increasing build time and bandwidth usage.

podman build --no-cache -t my-app .

Clarification on --mount=type=cache

The RUN --mount=type=cache instruction is designed for persistence, not invalidation. It allows package managers (like apt or dnf) to reuse downloaded archives across different builds to save time. However, it does not influence the layer's cache key. If Podman sees "Using cache" for the RUN step, it will not even execute the command, meaning the cache mount is never accessed and external updates are ignored.

Verification

To verify if a layer was actually rebuilt or pulled from cache, use the following command to inspect the image history:

podman history my-app

Check the timestamps and layer IDs to ensure the RUN step was executed at the expected time.

Diagnostic Detail: Are you using a specific build backend (e.g., BuildKit via BUILDKIT_INTEGRATION=1) or the standard Podman build process? Some advanced backends handle mount-based caching differently, though the fundamental RUN cache key logic remains the same.