https://pantsbuild.org/ logo
Join Slack
Powered by
The `pants_hash` variable that can be baked into d...
# general
a
The 
pants_hash
variable that can be baked into docker image tags - is that a thing that exists for other rules? I have a long-standing problem with attaching versions to front-end assets, where a subtree hash of build inputs would be perfect.
c
If you are writing a plugin, then yes. It is not available as a value for your BUILD files out of the box besides the interpolation value for the docker_image target.
a
Makes sense, ta.
b
https://github.com/pantsbuild/pants/issues/8445 is somewhat related, as is the crude approach listed in https://github.com/pantsbuild/pants/pull/18383 (although that’s error prone)
🙂 1
c
@average-breakfast-91545 does this look useful to you in this context? https://github.com/pantsbuild/pants/pull/20650
a
Yes, yes it does. I'm thinking of using it to tag the version of front-end assets. Right now we use a build number, but that changes on each build which mean we end up deploying things that needn't actually change.
I have a related problem with docker, where i use the docker json output as an input to our terraform and serverless deploys. I'm hoping that I can, instead, use the pants hash so that - again - we only need to deploy things that have actually changed, and we don't need to build every docker image if only one is different.
👍 1
c
would love it if you have feedback on that PR if you feel there's some rough edges that could be smoothed out for you 🙂 (as there's some limitations, like it can only hash source files on disk.. nothing built/generated, etc.)
a
That might be an issue. I'm dockerising pexes using the pattern on your blog, one pex for deps, one for sources.
c
would it work to hash the lockfile(s) and sources that go into the pex?
a
But I'll take a look. I'm planning to kick off a project to improve build/deploy times in the next week or two.
Sources yes, if I can find them transitively (sorry, didn't look at the code yet). We have a single lockfile across all deps, but that would still be better than the status quo.
c
I imagine the lockfile could give a few potential false positive changes if unrelated 3rd party deps get bumped... 🤷
you can do 
pants_hash("/src/to/lib/**/*.py", ...)
the drawback being the list of sources is disconnect from your actual pex dependencies...
a
If I do pants_hash("src/some_entrypoint.py") will that reflect the dependencies of the entrypoint? That's really the thing I need. I can imagine it's not terribly hard to write a plugin for.
And it would still save bags of time versus actually building the docker image and pushing them all sequentially
c
yea, no this only gets the hash for the file itself, so if depdencies change, that is not reflected
a
Yeah, I have a big ol monorepo. If I have to list every file that's transitively included in a pex, that's a non-starter.
c
yea, I can see that... I'll go have a ponder.. would likely need another approach, as the current state of the PR uses stuff at BUILD file parse time, so targets are not available to introspect at that phase...
a
For example, we generate code per-customer to define configuration, and when that config changes there might be 5 or 6 lambdas that need to be updated. This definitely feels like a thing that Pants is set up to help me with. If i have to add the customer files to each lambda every time we add a new customer, that'll be a pita to maintain and it will break.
➕ 1
the codegen happens outside of our packaging step, the results are committed.
👍 1
c
how do you expect to get/access this hash value? as a field value, or through introspection or something else..?
a
Haven't a clue! For the docker case, currently, I run a script that parses the docker json and extracts the value. I could do the same thing and write the hash to disk, or I could invoke pants and get it as command line output.
👍 1
I have no expectations, only urgent desires.
😂 1
Open in Slack
PreviousNext
Powered by