Hey everyone, just qq.. when listing targets that ...
# general
w
Hey everyone, just qq.. when listing targets that are
files
(or
resources
) seems like the pattern
Copy code
src/python/cool_thing:my_app
doesnt happen. I have some tags for
pex_binary
and
archive
and they return as I mentioned above.. but for files.. it’s returning like:
Copy code
src/python/cool_thing
src/python/cool_thing/Dockerfile
w
do you mean that you have
tags
on your targets? and then you’re trying to match them with
./pants --tags=.. $goal
?
w
yeah so I wanted to get only my Dockerfiles folders (path), and I’d do that before pants v2 with
./pants --changed…. --tag=docker list
and splitting that
:
afterwards so I can get the folder where the Dockerfile lives and do what I have to do with it.
w
and you have
--changed-dependees=transitive
in there?
w
yup
w
does
./pants dependencies --transitive $dockertarget
show the changed file/target?
👍 1
w
It is recognizing what it needs to be re-built, the only odd part is that for this particular case it should build 2 new images… but it’s trying to build 4.. lol… bc the way that I’m getting the target list back changed. It expected something like:
Copy code
services/docker/projectA:project_a
services/docker/projectB:project_b
but now… I get four different ones 😆
Copy code
services/docker/projectA
services/docker/projectA/Dockerfile
services/docker/projectB
services/docker/projectB/Dockerfile
I can change the rest of my Jenkinsfile to adapt to this new format but I just wanted to make sure that this is what I should expect as output when listing
files
and
resources
w
ah, got it. yea, you’re just getting both the file-level targets and the manually declared targets. see the “explicit file addresses” block in https://www.pantsbuild.org/docs/targets#dependencies-and-dependency-inference
Copy code
services/docker/projectA
is a declared target named `projectA`… ie, it’s equivalent to
services/docker/projectA:projectA
whereas
services/docker/projectB/Dockerfile
is a file-level target.
w
is it possible to “hide” the file-level target?
w
not currently, but we expected to need to add support for filtering files vs targets when we added file level deps but hadn’t had anyone ask for it yet…
w
alright, so it makes more sense now, that was actually expected behavior
cool, let me re-learn some Groovy and get rid of the file-level targets one 😂
w
yea, sorry about that. changed during the 2.0.x alphas. you might also consider consuming the file level targets rather than the directories… they seem easier to match (filename ==
Dockerfile
)
w
haha nothing is easy when using Jenkins and Groovy 😢 I had to wrap
pants
command inside a groovy function lol
frankenstein
w
heh
w
Thanks for all the info @witty-crayon-22786!
w
sure thing. i’ll open a ticket to discuss how we might make filtering these more consistent.
👍 1