Another odd case from one of our engs. They report touching a test file, then seeing us run the lint tools on the one file. Then a few pants runs (with the same exact cmd) later they see us run the lint tools on the "bucket" of files that test file is in.

hm, so: as it stands, the bucketing won’t coarsen up into larger buckets than have been specified. so if you ask to lint one file, one file will be linted (we won’t expand to a larger group)

Assuming other files in that bucket were modified, that is

Assuming other files in that bucket were modified, that is

no: regardless of that. the single file in the bucket was modified. there are two cache keys: one for the run with the single file, and one for the run with the bucket

So if there's 2 files modified, what happens?

Actually better question is if I only ever used the same --changed commands for specs, when would it bucket vs not

we always bucket: but we bucket the inputs, rather than expanding the inputs into some larger set of inputs and then bucketing those.

Oh right

So the only way we'd run the lint tools on 300-ish files is if pants thinks that many have been changed

correct

Now to figure out why that's our spec 😂

um, maybe not from the workunits, but from the raw run data, or debug logs maybe? at a fundamental level, all

--changed

is doing finding some “roots” which directly changed, and then (if

--…=transitive

) including the transitive dependees

I noticed a file being fingerprinted that was unexpected in the workunits, and has lots of transitive deps. My current suspicion is for some reason Pants is using it to calculate specs

if you have direct access, i would suggest:

./pants --changed=.. list

to see what it thinks have been directly changed