Seems not a day passes when I don't find something...
# general
Seems not a day passes when I don't find something else to not understand ๐Ÿ™‚ ๐Ÿ™‚ I'm playing with the new "pants-hash" functionality for docker image tags (2.10.0.dev1) Love it love it love it. Thanks a ton! ...and as usual, more questions ๐Ÿ˜„ first-- Is it possible to also tag with the existing git hash (or tag with an environment variable, which would be very flexible)? The reason I ask is that we've been tagging our production containers with the SHA of the commit which produced them in case we have to do hot-fixes (makes it terribly easy to figure out what tree they were built from). We've used good old
git log -1 --pretty=%H
to get the SHA. So the idea is that we'd tag each container both with a "git hash" (which would be different for each build) and a "pants hash" (which ideally wouldn't change unless the input context changed). We wouldn't deploy a container unless the "Pants hash" changed, but with the "git hash" on there we could look up the commit. Second--this is possibly better handled by the docker tooling, but since it relates--is it possible to get information about targets (in this case, such as the pants-hash) in any form, particularly human-readable? In other words, it would be nice (again, no need for extra work yet!) to say "okay, once we've built these, what would the image names and tags be of all the built containers in this repository?" so that we could then programmatically update deployments. I know some of this may fall outside the purview of the build tool itself, but this is great stuff for us and it's also just fun to learn.
โค๏ธ 2
And, more obscure, for the second question:
As John pointed at, thereโ€™s in the documentation how to incorporate an environment variable into the image tag.
Copy code
$ GIT_COMMIT=$(git rev-parse HEAD) ./pants package src/example:demo
About the second, unfortunately,
will not reveal the final image name with registries and tags with all values interpolated.
If you run
to push the images, you can get a readable output in json format detailing what was just published. See
The json file looks something like this:
Copy code
$ jq . publish.json 
    "exit_code": 0,
    "names": [
    "published": true,
    "publisher": "docker",
    "registries": [
      "<all default registries>"
    "status": "published",
    "target": "docker:kratos-images#oryd_kratos"
Brilliant, brilliant; I had not in fact seen that, John. This is going to be lovely!
Andreas--thanks for that as well; this should do the trick.
Keep them questions coming, love it ๐Ÿ™‚
Yep, easy to work the git sha in with the env variable; that worked a treat. I see what you mean about peek, Andreas--lots of info but not interpolated, so I'll try the publish method although I may just need to query the repo in some way (otherwise I either need to cache the publish output or force a full build before any deploy). Hmm, I think all the pieces are in place, just need to assemble them. Very nice.
๐Ÿ‘ 1