https://pantsbuild.org/ logo
Join Slack
Powered by
I'm seeing an unexpected behavioral change when up...
# general
b
I'm seeing an unexpected behavioral change when updating from 2.10.0 to 2.11.0. I generally run Python tests in this particular repository with the following: 
./pants filter --target-type=python_tests :: | xargs ./pants --tag="-e2e" test
. This worked fine with 2.10.0 and appears to have started failing with 
2.11.0.dev0
. The failure comes with the tag-based filter: my tests that are tagged as "e2e" tests (which I don't want to run in CI when I'm trying to do unit tests, since they rely on external infrastructure resources) are also being run, and are not being filtered out. Even taking out the 
xargs
bit and just running 
./pants --tag="-e2e" test ::
fails. Has anyone encountered something similar? Any pointers on how to deal with this? Thanks 🙇
h
I am wondering if this might be https://github.com/pantsbuild/pants/issues/14977
I finished moving from Arizona to Mexico City this weekend, so I'm catching up on things and planning to invest some time into closing broken windows like this
But, you should try using that same command only with 
python_test
w/o the s. The tags get copied to each generated target
b
Hrm... I think 
./pants --tag="-e2e" filter --target-type=python_test :: | xargs ./pants test
works... had to shift the 
--tag
option to the 
filter
command, though.
🙌 1
As always, thanks for the assist @hundreds-father-404 🎉
❤️ 1
h
@brash-baker-91190 how are you specifying the 
tags
field? Can you please share a sample BUILD file?
b
@hundreds-father-404 It's basically just this in a BUILD file:
Copy code
python_tests(tags=["e2e"])
👍 1
h
thanks. im trying to fix tags today
b
snazzy 😄 🎉
h
ohhhhhh @witty-crayon-22786 we made 
tags
a moved field, which means that now the target generator does not have 
tags
-> 
--tag=-bad
does nothing
w
it will exclude the files, but not the generator
h
Yeah maybe solving #14977 would also solve this -- but do note that #14977 is applicable for 2.10 whereas this is a regression from 2.11
w
…but yea. makes sense.
h
Generally, any reason 
tags
and 
description
should be moved rather than copied? I see no benefit. Not like you're gonna parametrize
w
um. yea, probably not?
but i think that the fix from #14977 (filtering before generator expansion in addition to after) makes that moot
h
I'll still start with this fix. Seems like we want 
./pants --tag=-bad filter --target-type=python_tests ::
to still filter how folks would expect
w
imo, it’s cleaner to apply tag filtering in both places, without relying on which target the tags are on.
but up to you.
for example: i don’t think moving or not moving the tag would fix the bug for a single file overridden with a tag
i.e. 
./pants --tag=-bad filter --target-type=python_tests ::
would still break for 
python_sources(overrides={'one.py': {'tags': ['bad']}})
h
Turns out 
python_tests
is the sole target type where we move rather than copy. I think it was oversight
Yep, still need to fix 14977. But 1/3 issues now fixed, yay
2/3 fixed.
Copy code
❯ ./pants --tag='demo' list 'src/python/pants/util/*util*.py'
src/python/pants/util/strutil_test.py:tests
14977 remains a head scratcher for me
3/3 fixed, and I'm pretty okay w/ the solution
🙌 1
3 Views
Open in Slack
PreviousNext
Powered by