Hey folks, we're currently building some docker im...
# general
l
Hey folks, we're currently building some docker images with pants, using them to contain some pex binaries. Everything is working as expected, but I've run into a bit of a snag when it comes to tagging. We want to tag the images with the same version as we are using for the pex. We obtain these versions from files kept alongside the source (in a format readable by Hatch). I'd like to be able to read these version files per-target during build and use the version in there as an image tag. I saw in the documentation that anything beyond using ENV values for tagging would likely require a plugin and I've been trying to determine what sort of rule I would need to create to hook into this tagging process.
h
We have some ansible tooling that we use at times to build our packages which lets us do things like setting env vars ahead of time properly so that we don't have to make a plugin.
So in that kind of paradigm, you could image a step being to parse the file and then set env vars appropriately.
Not sure of the exact question or if maybe you're just looking for confirmation
c
docker image tagging certainly proves as an area for exposing a plugin hook point for. currently there isn’t much of the sort, unfortunately.. (feature request driven development one could call it 😉 )
l
yeah we were looking at something similar, or simply using
cat
during invocation to set the env. But it seemed to fall apart for a couple of reasons. First we use the version files as sentinels to trigger builds on our main branch after merge, meaning there may be multiple builds happening, and we'd want to source distinct versions for each build. Additionally as we use the same hatch-compatible format for all version files across the repo, there is a little bit more in them than just a version triple on the first line, which requires parsing
in this case is a custom target a more realistic place to start looking?
c
I’ll ponder on it for a few minutes…
Hmm.. yes, actually I think that could work out pretty well, with a custom target derived from
docker_image
.
It would be a little bit more involved than I’d like, I think, and would likely requiring subclassing the
DockerFieldSet
in order to have a custom rule to build the image with the custom set of tags (could still re-use the existing rule for the heavy lifting)
this is silly…
(as in, there should be a better way)
l
Well I can give it a shot tomorrow and see how far I can get. I'll keep you posted on how I get on with it. Thanks so much for the replies and info @high-yak-85899 and @curved-television-6568 !
👍 1
I'll likely have some more questions too 😆
c
questions are always more than welcome 🙂
l
Well @curved-television-6568 I managed to get a working plugin. But with the amount of stuff that needed to be messed with + my current knowledge of the internals of pants let's just say I really hope I get to use the change in your PR soon and no one ever sees what I made 🤣
🤣 1
c
Impressive nonetheless :D
l
Oh one thing I did want to ask about your PR is at what point we can get the file target to read the value. It appears it would be in the actual
@rule
function?
c
Yes, in the rule. 👍🏽
👍 1