Hey! Seeing the end of the tunnel to get all our p...
# general
l
Hey! Seeing the end of the tunnel to get all our platform on pants 1.30 🎉 . Right now trying to figure out a strategy for versioning. I was thinking having a python function that would be available in all BUILD files to be able to get the version or a commit hash. I was looking in the plugins docs and that explains targets and tasks but it doesn't feel like that would fit in there. Thank you
w
you can use a BUILD macro to inject a version
macros cannot read files, but if you’re ok editing the macro definition to bump a version…
commit hash is slightly more challenging right now, although possible. would need more details about which BUILD symbols need to consume it.
l
the commit hash would be for the docker tags, feels like I could customize the plugin itself since I have that already
we would want every image to be tagged twice
with the commit hash
and the propective version
and at release just tag the release on it
w
the challenge with doing it via a plugin is effectively: https://github.com/pantsbuild/pants/issues/7022
l
Does this mean that I could build an arbitrary function in a macro but it just needs to be a pure python function (no external dependencies)?
w
yea, a pure function would be safe
the challenge is that interacting with git would violate that
l
Hum - what strategies have you guys seen in the past?
I am also thinking of the python lib publish function we will need to be able to inject something in there
w
there are better facilities for this in v2 (uncacheable rules, passing things as options, etc), but in v1, the surest defense is to very lazily apply
l
😛
w
if you have a v1 Task, wait until you are running the Task to choose the version, and run the logic there… ie, don’t do it in your BUILD file
doing it in a v1 Target constructor is safe as well, actually. it’s basically just that you can’t do it in a macro.
l
That gives me food for thoughts, thx!
w
yep, sorry for totally misleading you at the start 😃
l
no worries 🙂