pantsbuild / pants / 5305
0%
main: 93%

LAST BUILD BRANCH: fix/single-source-hydration
DEFAULT BRANCH: main
Ran
Jobs 10
Files 331
Run time 19min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
5305

push

travis-ci

Benjy 
Add a global --tag option to filter targets based on their tags.

--tag=foo,bar includes only targets that have at least one of those tags.
--tag=-foo,bar includes only targets that have none of those tags.
--tag=foo,bar --tag=-baz includes only targets that have at least one
  of the tags foo or bar, and do not have the tag baz.

The filtering is on target roots, of course, similar to spec_excludes and
exclude_target_regexp. Dependencies are included in the targets passed to
Task.execute() regardless of their tags.

We already had similar filtering functionality in the Filter task. So I
refactored some of that into a new filtering.py file under util.

While doing so, I noticed that the help text on Filter's options was wrong:
In --tag=-foo,bar the '-' prefix applies to both foo and bar, and
--tag=-foo,+bar is not sensible. While fixing up the help strings I realized
that it would be more succinct to move the common help text (the part
explaining about the prefix and how multiple filters are specified) into the
goal description.  Then I realized that it would be pretty verbose to put that
in the with_description() text in register.py, so I added a little thing that
uses the task's docstring as the description, if one isn't provided explicitly.

Note that Filter still has its own --tag option, which we can think
about deprecating in a future change.

IMPORTANT: While testing, I noticed that we had a longstanding bug, where
multiple filters of the same type wouldn't work, because in the loop the
filter() function was capturing the same references in its closure on each
iteration. See the test I added in test_filter.py - that test fails with no
other changes at HEAD.

Also note that the test marked as xfail is behaving as intended: according to
the implementation, separate specifications of the same option are ANDed
(while comma-separated values in a single specification are ORed). If we want
the behavior to be different then we can discuss, but for now at least that xfail
was inappropriate and misleading.

Testing Done:
CI passes: https://travis-ci.org/pantsbuild/pants/builds/66695055

Reviewed at https://rbcommons.com/s/twitter/r/2362/

13956 of 19909 relevant lines covered (70.1%)

1.32 hits per line

Jobs
ID Job ID Ran Files Coverage
1 5305.1 (CI_FLAGS="-cjlpn 'Various pants self checks'") 0
Travis Job 5305.1
2 5305.2 (CI_FLAGS="-fkmsrcn -u 0/2 'Unit tests for pants and pants-plugins - shard 1'") 0
65.76
 Travis Job 5305.2
3 5305.3 (CI_FLAGS="-fkmsrcn -u 1/2 'Unit tests for pants and pants-plugins - shard 2'") 0
65.8
 Travis Job 5305.3
4 5305.4 (CI_FLAGS="-fkmsrcjlp 'Python contrib tests'") 0
Travis Job 5305.4
5 5305.5 (CI_FLAGS="-fkmsrjlpn -i 0/6 'Python integration tests for pants - shard 1'") 0
Travis Job 5305.5
6 5305.6 (CI_FLAGS="-fkmsrjlpn -i 1/6 'Python integration tests for pants - shard 2'") 0
Travis Job 5305.6
7 5305.7 (CI_FLAGS="-fkmsrjlpn -i 2/6 'Python integration tests for pants - shard 3'") 0
Travis Job 5305.7
8 5305.8 (CI_FLAGS="-fkmsrjlpn -i 3/6 'Python integration tests for pants - shard 4'") 0
Travis Job 5305.8
9 5305.9 (CI_FLAGS="-fkmsrjlpn -i 4/6 'Python integration tests for pants - shard 5'") 0
Travis Job 5305.9
10 5305.10 (CI_FLAGS="-fkmsrjlpn -i 5/6 'Python integration tests for pants - shard 6'") 0
Travis Job 5305.10
Source Files on build 5305
Detailed source file information is not available for this build.