Expose the hash of a given target #8445
Labels
Comments
|
This is actually something that would be immediately useful for IDE support in Metals too (from scalameta/metals#935), and it would almost definitely be generically useful in the way you describe. |
huonw
added a commit
that referenced
this issue
Mar 3, 2023
This has the `peek` output include the fingerprint of the sources referenced in a target. This is a step towards #8445, by putting more information into `peek`. For instance, with this, one way to get a crude "hash" of a target would be something like: ```shell { pants dependencies --transitive --closed path/to:target | xargs pants peek # these might change behaviour and so need to be included cat pants.toml cat 3rdparty/python/default.lock # or whatever other lock files are relevant } | openssl sha256 ``` This is conservative: the hash can be different without the behaviour of the target changing at all. For instance: - irrelevant changes in `pants.toml`: adjusting comments, unrelated subsystem config (e.g. settings in `[golang]` when `path/to:target` is a Python-only `pex_binary`) - upgrading 3rd party dependencies in the resolve that aren't (transitively) used by `path/to:target`. This relates to #12733: if all transitive 3rd party deps appeared in `pants dependencies --transitive`, and `pants peek` included the right info for them (e.g. version and fingerprints), the `cat 3rdparty/...` could be removed because the `peek` pipe would handle it. - target fields that don't impact execution behaviour, e.g. changing the `skip_black` setting on a `python_source` target, without changing the file contents (this might be _most_ fields on the (transitive) dependencies of a packageable target?) This is also only the hash of the input configuration, rather than a hash of a built artefact. If there's processes that aren't deterministic (e.g. `shell_command(command="date > output.txt", output_files=["output.txt"])` somewhere in the chain), the exact output artefact might be different if built twice, even if the hash hasn't changed. This PR is, in some sense, a partial revival of #8450, although is much simpler, because the JSON-outputting `peek` target already exists, and this doesn't try to solve the full problem.
|
N.b. for those coming here, tagging images built with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This has come up several times for our team, but it would be nice to have access to the hash of a given target. Most recently, we're building PEX files with pants and then dropping them into Docker Images--we'd like to tag the Docker Image with the hash of the PEX's inputs so our deploy pipeline will see that the image tags are the same and not trigger a redeploy.
We could hash the PEX file, but then we're at the mercy of pants to produce exactly (bit for bit) the same PEX file with each build. Admittedly, a shared cache probably makes this mostly an academic concern.
I'm not familiar with pants internals, but ideally this would be agnostic to the type of target--the same use case could easily apply to Node or Go images as for Python.
The text was updated successfully, but these errors were encountered: