Hi, we’ve found out recently that touching a BUILD file essentially invalidates all the targets defined in the BUILD file, even the ones that had not been changed in any way. This behavior leads us to run a lot more tests than strictly necessary when we compute the changes of a diff / PR (with

--changed-parent

and

--changed-include-dependees

). Is there a way to compute precisely the targets that have been impacted by a change?

hey @fierce-plastic-71129! yes, the

--changed

flags will report those targets as potentially changed.

How often are y'all changing BUILD files? With dependency inference, our hope is that it's rare you need to make a change. But it's plausible folks are changing more than anticipated Another thing that can help to minimize the impact is to use one BUILD file per directory, which is now automated with

./pants tailor

. See https://www.pantsbuild.org/docs/targets#target-granularity-for-first-party-code for the guidance there (to be clear, not required to do)

I see. We’re still on an old version of pants (

1.11

) so we’re not using dependency inference. For local tests, it’s indeed not much of a problem since those are cached. But on a build server, you can’t always assume that the test cache will be warm. More generally speaking, I think there is a need to know exactly what targets have changed as a result of a change. For example, we have a custom target type for a service and we want to detect exactly what services need to be redeployed after a change is landed. We were hoping to implement this logic using the pants but due to the false positive, it looks we’re going to have to re-implement all of this ourselves.

ah… yea, 1.11 is quite old

Sounds good. Thanks!

@fierce-plastic-71129 would y'all be interested in upgrading to Pants 2.x? It generally is a much more enjoyable and often more performant experience than 1.10 is giving you. For this particular question, dependency inference should substantially cut down on editing BUILD files - it removes about 90% of BUILD file content usually

As far as I understand, it would be a rather large migration because use many languages (python, java, custom targets for js, webpack, custom targets for go, and more) and we have over 10K targets. I’m not familiar with the new dependency inference system but we have rather large mono-repo so we would need the inference to be performant and precise.

there is more information about dependency inference here: https://blog.pantsbuild.org/dependency-inference/ … BUILD files get smaller, but also: dependency information gets much more accurate.