https://pantsbuild.org/ logo
Join Slack
Powered by
What’s the default scope of running for `pants tes...
# general
w
What’s the default scope of running for 
pants test ::
? Does it automatically try to figure out whether a change will cause transitive problems? Or if my changed file is in a package, and that package is referenced elsewhere? Does any of this change if the changed file is located within a batch_compatibility_tag?
Essentially, I’ve tried most of what I can think of to figure out why 
pants test ::
(without transitive deps) is re-running tests that seem to be located in a separate test batch. The fact that the tests are running is arguably good, but I’m more concerned about where that is decided
c
Sorry if I'm missing something fundamental, but isn't 
::
"all the thing" regardless of what changed?
w
Oh, ha, sorry, missed an important bit - the batches are/should-be memoized
So, the part that is confusing to me is that, several batches become unmemoized and re-run, in spite of a one line change in one file that "should" be unrelated to all the others (unless everything is re-run transitively)
c
package
As in 3rdparty? We talking Python here?
w
Yeah, python code, as Pants dependencies pulled into other sub projects in the same monorepo
Like, essentially, this feels like some batch shenanigans, or 
pants test ::
is doing more than it needs to
h
Not sure what you’re asking, but if you change a file that a test transitively depends on, that test will re-run. But I assume you know that and you’re asking about something else?
w
Yeah, I’m having a hard time explaining the problem I’m running into (and spent hours debugging). What I’m getting at is that tests that aren’t direct dependencies of the changed file, are also re-running. OR, changing a file affects multiple batches of tests - causing them to also be re-run instead of using the memoized versions. Like, “too much work is being done” would be the only way I can explain it
E.g.Changing 
foo.py
causes 
test_foo.py
to re-run - cool, perfect, no problem. But, in my case, 
test_foo.py
re-runs, and 
test_some_seemingly_unrelated_file.py
also re-runs even though there is no direct link between that test file and 
foo.py
except via some long chain of transitive dependencies. An alternate explanation is that, changing 
foo.py
causes the test batches_compatibility_tag to be re-calculated and then two unrelated batches just end up being re-run
h
Well, yes, if there is a transitive dep chain then I would expect the test to rerun
if 
test_foo.py
depends transitively on 
test_some_seemingly_unrelated_file.py
then it will rerun when the latter changes
and I wouldn’t say in this case that is is unrelated, it is a dependency!
w
test_foo depends on foo 
test_some_seemingly_unrelated_file.py
depends on foo.py via like 10 linked files, but not all of the related tests in the middle run, necessarily. Also, isnt' this one of those cases where we'd normally write 
pants --changed-dependents=transitive test
or something to get this behaviour?
And like, through some random manipulation, I've occasionally been able to make it so that a change to foo.py does NOT cause ``test_some_seemingly_unrelated_file.py` to re-run, so I'd be surprised if it was this deep transitive behaviour causing it - because in that case, I shouldn't be able to NOT make it happen 🤷
In short - weird behaviour I can't explain.
h
Which is the file you’re editing?
I assumed it was 
foo.py
w
Yeah, so 
foo.py
is edited, but files related by long distances -sometimes- run their tests This is why I was thinking it was a batching problem, which might explain away the behaviour Im seeing. I don't know much about batching
I've been trying to come up with a reproduction, but I've only seen it in this one private repo 😩
7 Views
Open in Slack
PreviousNext
Powered by