-
-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export metadata about a packaged docker image #17299
Conversation
[ci skip-rust] [ci skip-build-wheels]
Re writing generated data out to a file: you create a
and then materialize that under |
[ci skip-rust]
[ci skip-rust]
Thanks. I've added that. It seems like setting Thus, I think this is now ready: with the example above, running
(Where And, a Python test that depends on the image passes too: (and similarly for
import pathlib
import json
def test_whatever() -> None:
with pathlib.Path(".../docker.docker-info.json").open() as f:
data = json.load(f)
assert data["registries"].keys() == {"other-example.invalid", "@demo-reg"} |
[ci skip-rust]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the belated review. This is some cool stuff, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
This is looking great. I'll wait for some more feedback from the other maintainers a few days. If nothing comes up I think we can merge this early next week.
Woohoo, thanks. Now that we've agreed on the approach, I've written a paragraph of documentation too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! Thanks!!
Will this be available in 2.15 or how does things work? 🙂 |
Looks like it's slated for 2.16. |
Maybe we could keep a record of cut-dates (and |
|
The Github's commit view can answer that too, although I suspect neither that nor |
Ah, cherry picks. Good point. 🤔 again... |
This has the docker target output a
$name.docker-info.json
file when packaged, to end up indist/
or for use as a dependency. The file contains the full specification of the packaged image, including each of theregistry/repository:tag
names it was tagged with. This stops users from having to parse the pants output (or querydocker
itself) if they need this information, such as to place into a cloud deploy template, or to run the image locally.This is achieved by defining dataclasses to set the schema of the JSON file (as discussed in #16999 and https://pantsbuild.slack.com/archives/C0D7TNJHL/p1664329466314179), which are then serialised via
asdict
/json.dump
. The schema is relatively nested (not just a flat list of image names), so a user can easily look up a specific tag, even in the presence of templating, and different registries using different tags. This requires refactoring theimage_refs
function to return all the information.For example:
Packaging the
docker
image results in JSON like the following:Someone who wants to pull out the
example.invalid/prefix/docker:pants-baee6c62401aae07329ab65c6d39ae9be558b5d4ab2feae89e1495d7bd1f6764
full name for@demo-reg
tag can query (in JS/TS):In #16999, I flagged including the 'digest', which allows referring to the image in a content-addressed manner:
registry/repository@digest
(rather than just via a tag, likeregistry/repository:tag
, which are mutable). However, the digest is not available until the image is pushed (to a v2 registry), and thus is omitted.Fixes #16999
[ci skip-rust]
[ci skip-build-wheels]