https://pantsbuild.org/ logo
#general
Title
# general
b

brash-baker-91190

05/03/2022, 6:20 PM
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

hundreds-father-404

05/03/2022, 7:00 PM
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

brash-baker-91190

05/03/2022, 8:01 PM
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

hundreds-father-404

05/10/2022, 8:37 PM
@brash-baker-91190 how are you specifying the
tags
field? Can you please share a sample BUILD file?
b

brash-baker-91190

05/10/2022, 9:19 PM
@hundreds-father-404 It's basically just this in a BUILD file:
Copy code
python_tests(tags=["e2e"])
👍 1
h

hundreds-father-404

05/10/2022, 9:33 PM
thanks. im trying to fix tags today
b

brash-baker-91190

05/10/2022, 9:33 PM
snazzy 😄 🎉
h

hundreds-father-404

05/10/2022, 10:40 PM
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

witty-crayon-22786

05/10/2022, 10:41 PM
it will exclude the files, but not the generator
h

hundreds-father-404

05/10/2022, 10:42 PM
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

witty-crayon-22786

05/10/2022, 10:42 PM
…but yea. makes sense.
h

hundreds-father-404

05/10/2022, 10:43 PM
Generally, any reason
tags
and
description
should be moved rather than copied? I see no benefit. Not like you're gonna parametrize
w

witty-crayon-22786

05/10/2022, 10:44 PM
um. yea, probably not?
but i think that the fix from #14977 (filtering before generator expansion in addition to after) makes that moot
h

hundreds-father-404

05/10/2022, 10:46 PM
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

witty-crayon-22786

05/10/2022, 10:50 PM
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

hundreds-father-404

05/10/2022, 10:53 PM
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