buck2
is very explicit re: the interactions dep files have w/caching:
- dep files can (after execution) narrow the set of inputs for an action
- the input set of the action as known to your
buck2
daemon will have this narrowed set but...- the actual action cache key (as is given to disk/remote caches, etc.) will still have the full set of inputs
- ultimately this means that as far as remote caching for cold builds is concerned, the action at hand is still keyed on all of its inputs — including the ones that are pruned
- this means that — for cold builds — if there have been any changes to any of the "pruned out" files since the last run of the action (+ cache population), the action will not hit in the cache
- additionally, in the event that there are analysis-level changes that result in the starlark action being reconstructed (i.e. BUILD file is edited), we also lose the narrowed set of inputs
- for changes that materially affect t