I m seeing an unexpected behavioral change when updating fro

Question

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 bow

hundreds-father-404 · Answer

I am wondering if this might be <https github com pantsbuild pants issues 14977>

hundreds-father-404 · Answer

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

hundreds-father-404 · Answer

But you should try using that same command only with `python test` w o the s The tags get copied to each generated target

brash-baker-91190 · Answer

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

brash-baker-91190 · Answer

As always thanks for the assist < hundreds father 404> tada

hundreds-father-404 · Answer

< brash baker 91190> how are you specifying the `tags` field Can you please share a sample BUILD file

brash-baker-91190 · Answer

< hundreds father 404> It s basically just this in a BUILD file ```python tests tags= e2e ```

hundreds-father-404 · Answer

thanks im trying to fix tags today

brash-baker-91190 · Answer

snazzy smile tada

hundreds-father-404 · Answer

ohhhhhh < witty crayon 22786> we made `tags` a moved field which means that now the target generator does not have `tags` gt ` tag= bad` does nothing

witty-crayon-22786 · Answer

it will exclude the files but not the generator

witty-crayon-22786 · Answer

which is still <https github com pantsbuild pants issues 14977> i think

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

but yea makes sense

hundreds-father-404 · Answer

Generally any reason `tags` and `description` should be moved rather than copied I see no benefit Not like you re gonna parametrize

witty-crayon-22786 · Answer

um yea probably not

witty-crayon-22786 · Answer

but i think that the fix from 14977 filtering before generator expansion in addition to after makes that moot

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

imo it s cleaner to apply tag filtering in both places without relying on which target the tags are on

witty-crayon-22786 · Answer

but up to you

witty-crayon-22786 · Answer

for example i don t think moving or not moving the tag would fix the bug for a single file overridden with a tag

witty-crayon-22786 · Answer

i e ` pants tag= bad filter target type=python tests ` would still break for `python sources overrides= one py tags bad `

hundreds-father-404 · Answer

Turns out `python tests` is the sole target type where we move rather than copy I think it was oversight

hundreds-father-404 · Answer

Yep still need to fix 14977 But 1 3 issues now fixed yay

hundreds-father-404 · Answer

2 3 fixed ``` 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

hundreds-father-404 · Answer

I m stumped on if anyone has ideas

hundreds-father-404 · Answer

3 3 fixed and I m pretty okay w the solution