Is there a way to limit the depth of `--changed-de...
# general
h
Is there a way to limit the depth of
--changed-dependees
when using advanced target selection? For example, only go 4 links away or something like that?
b
Not that I'm aware of.
FWIW I'd love to see more customizability in
--changed-dependees
and have sketched out at least one potential option. However the system it's built on "specs" is liekly due for an overhaul anyways
h
Yeah, I didn't see it in the docs, but I just intentionally made the argument wrong for that and saw that none, direct, and transitive are available.
imo, transitive seems to go way too deep to be useful for the target selection once repos start to get really large.
ooo, I thought of something tricky for how you can do it
I remembered reading about piping arguments
So I can do
Copy code
./pants --changed-since=master --changed-dependees=direct list | xargs ./pants dependees | xargs ./pants test
and that will run all tests two layers of dependencies deep
h
Hm, you do need to traverse fully for correctness though.
./pants --changed-since=HEAD --changed-dependees=transitive test ::
tests everything that might have been impacted by your change. If it's only a few levels, then you will be missing some deps. What's the motivation?
h
I want to minimize the amount of time it takes a developer to put up a change. Our build system will do the potentially heavier full validation for them because it has remote caching set up and can share work more easily. We haven't enabled remote caching for developer machines yet until we get more confidence of the load on that system.
So, I'd like to run enough tests that should indicate things will probably work and then let devs respond appropriately if CI disagrees.
👍 1
Since we develop in multiple languages, it can be a while since someone has run tests in this portion of the repo and their cache would be so out of date that they'd have to run everything.
w
the double-dependees thing is a neat trick, heh. but yea, those goals could probably pretty easily support a numerical level
h
Yeah that seems like a reasonable thing to support, if you want to put up a change? :)
h
lol, I'm building up quite the queue. When things cool down on the Astranis side (will it ever?) I'll start poking around the contributor page and get acquainted. This seems more reasonable to tackle as a first task than getting pyright type checking supported.
h
Haha I feel you there, so many changes I want to do too. Would you be willing to open a feature request please, including your (very helpful!) explanation for why this would be useful? In case anyone else wants to chip in
h
Yeah, good idea. Will do that now.
b
FWIW contributing is super easy and fun. Would recommend 😉
🙌 1
🚀 1
h
in general, we're very happy to pair program on any changes also 🙂 (altho ack the issue here is time, no pressure at all! there's never an expectation you contribute certain things)
h
This would definitely be a better first ticket to get your feet wet on
If I may mix metaphors atrociously