https://pantsbuild.org/ logo
Join Slack
Powered by
hey, anybody got a sample plugin to fill docker_im...
# general
b
hey, anybody got a sample plugin to fill docker_image tags depending on environment variables at hand?
✅ 1
e
I think the feature you need is built in. See the "Tagging Images" docs here: https://www.pantsbuild.org/v2.10/docs/tagging-docker-images
h
Unfortunately it looks like the Docker example repo doesn't have examples of this
@curved-television-6568 when you return, something to add perhaps?
👍 1
b
well, right now the setup that works for me is with environment variables and mix of semver and pre-release plus a build number
says 
1.0.1{buildargs.PRE_RELEASE_BUILD}
which gives 
1.0.1-dev.1234
on develop and 
1.0.1
on main
the whole issue is developper experience
h
Ah then I'm not understanding the question. Can you explain a little more about what the feature you'd like is, and how it's different from the built-in ability to tag via an env var?
b
so, currently, we use 
1.0.1{buildargs.PRE_RELEASE_BUILD}
as mentionned
to be precise, 
{buildargs.COMPONENT_X_VERSION}{buildargs.PRE_RELEASE_BUILD}
we have a script that will populate 
PRE_RELEASE_BUILD
as needed depending on the branch
but for all of this to work, we use a script that performs the branch-build mapping and we'd like that logic to be transparent
because right now this forces use to populate the environment before running any pants command
h
What is 
buildargs
?
b
sorry, I meant 
build_args
as explained here
h
Oh I see, sorry, I thought this was some in-house construct. Right, makes sense.
So you want a plugin to compute the value of 
PRE_RELEASE_BUILD
instead of having to set it outside of Pants?
b
exactly, yes
or basically any pointer to something similar
it looks like something similar is fairly straight-forward for Python packages but I haven't had much success with Docker images
c
What I've done is to source a “ci-vars.sh” file from the “./pants” bootstrap script. That way it is transparent both in dev and on ci pipeline run.
b
that idea crossed my mind but thought I'd go for a cleaner approach
👍 1
I think I'll do that as well unless I find a better way along the way
thanks
c
If you find a cleaner way, please share ;)
h
A cleaner way might involve adding a plugin hook there
But TBH modifying the ./pants script seems pretty clean to me
You just have to remember to copy over the updates if you update 
./pants
We could add an env-var setting hook in the standard 
./pants
@bitter-orange-16997 that script lives in https://github.com/pantsbuild/setup/ if you want to send a pull request
So that future adopters of Pants can enjoy your work 🙂
h
A concern I have there is it makes it harder to consume updates to the 
./pants
script, you have to deal with merge conflicts now. Not the end of the world and seems viable for Benoit to work around this today, but I'm curious how else we could solve this before we memorialize changing 
./pants
script
b
well, yes. another issue is that that sort of versioning scheme affects all artifacts published (in most projects they follow a similar scheme, perhaps Docker images less so than other artifacts) and an ideal solution would integrate easily with all artifacts, including those handled by plugins
but well, this is good enough for now
h
We can add a hook into 
./pants
that brings in env vars from a sidecar script, if it exists
c
3 Views
Open in Slack
PreviousNext
Powered by