I know what a covering tree is for a given graph, ...
# general
b
I know what a covering tree is for a given graph, is the notion related ?
Your earlier description - all leaves - describes it. In general this will pick out all "binaries" for some definition of binary - in the input set.
b
thanks ! it's too bad it's not the message output by
./pants minimize --help
hmm
then I'm not sure to understand the proposed script here
<https://www.pantsbuild.org/orgs.html>
e
Well, a test target is a binary in that no other target should generally depend on it and it is runnable.
From that test target you cover the library it tests.
What this really does is emulate finding the "projects" in repo layouts that have a maven/sbt-style - multii-project layout instead of single source tree style layout (like pants itself uses).
b
ok, I understand why it excluded some of my tests target
e
Eliminitaing the last command in the pipeline so you just get the list of minimized targets is helpful for grokking.
b
we have test targets that are also "test-libs". we will do the split but we still need to finish our build tool transition first
e
Or, I guess in that form, just looking at minimized.txt
Aha - ok
b
I have another problem that I have not yet solved that is related. This setup is the one we do for prs and we filter the integration tests because they are too long.
We have a cron that do a full rebuild, integration tests included.
And then we have the target that publish the zip of the application. On this one we want to redo all tests and integration tests of its dependencies
my problem is how to compute the set of targets I'm interested in.
A first approximation was to take the transitive dependencies and one "step" of dependees, but since we will have this test-libs that introduce an extra step this doesn't do. And "two steps" dependees seems like an overapproximation …
do you have an idea on this subject ?
e
Not sure. Can you help me visualize? What is a minimal example of your graph? For example - something like this?:
Copy code
app -> lib
test -> lib, test-lib
integration-test -> ?
b
sorry I was commuting
we have something along the line
Copy code
app -> lib-a
app-test -> app
app-test -> lib-a-test-lib
lib-a-test -> lib-a-test-lib
lib-a-test-lib -> lib-a
XX-test-lib is not always present
but we could have
lib-b -> lib-a
where lib-b is not used by app
e
For your example,
./pants minimize ::
shuld produce
app-test, lib-a-test
. What do you want instead?
Basically, if you could phrase all this in I have, I expect, I instead get - that would be wonderful.
(I'm a bit slow)
b
no problem ! actually the last time I look at the problem I did't have
minimize
actually this may be exactly the tool I need !
thanks for pointing it out !
(next time I'm on the problem If what I get is not what I expect I will write it using this protocol ^_^ )
e
I'm slightly confused since https://www.pantsbuild.org/orgs.html includes the minimize goal, but if you're happy I'm happy!
b
I did'nt have
minimize
in mind since I didn't understood what it is supposed to do ^_^
f
instead of minimizing, would just filtering for ‘test’ targets achieve the same thing? or is there no actual way to ask pants for “just tests”, so minimize is the heuristic for that?
a
you can filter by target type — i think
./pants help filter
might be the right place to look?
f
yeah, I think that requires needing to explicitly spell out the different kinds of test targets you have, though (python_tests, java_tests, etc.)
mostly just want to make sure I’m understanding the intent of the
minimize
in that script, though
a
explicitly spelling out target types is exactly what we do in our internal ci. in the pants repo we also do things like e.g. have
tags={'integration'}
for integration tests which you can filter by for different ci shards. will look at the script to answer your question though
oh well "all leaves" like mentioned at the top of the thread seems to describe it
you can test this out just by running the task with different target sets as input, it shouldn't take long to complete