LGTM
A forced-(re)build might take time even with cache (baking a cache-efficient Dockerfile is an art), so I wonder we should guard this by comparison between last modified time for watched files and image's creation date.

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (0ab21a2) 56.83% compared to head (2ba5e4c) 56.82%.
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main   #11213      +/-   ##
==========================================
- Coverage   56.83%   56.82%   -0.01%     
==========================================
  Files         133      133              
  Lines       11486    11491       +5     
==========================================
+ Hits         6528     6530       +2     
- Misses       4321     4325       +4     
+ Partials      637      636       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

LGTM A forced-(re)build might take time even with cache (baking a cache-efficient Dockerfile is an art), so I wonder we should guard this by comparison between last modified time for watched files and image's creation date.

We have the --no-op flag to avoid building images for this, you think this may not be enough @ndeloof?

I agree with @ndeloof - that's something I've seen first-hand with Tilt, which has similar behavior. Some larger projects, even with efficient layer caching, could take a while just to run through and do context transfers etc.

That said, I do think that, even imperfect, this is a beneficial change, but we should look at using mtime (also imperfect) or other approaches to continue to refine the behavior