If I could get something like the hash of a docker...
# general
s
If I could get something like the hash of a docker_image’s deps, I could use buildkit, registry storage, cache-to / cache-from, and use the hash as a tag to basically get real CAS for docker. Currently I’m getting bit by index.jsons overwriting eachother. Is this something feasible as a plugin?
Nevermind, docker only allows one cache-to for some resaon
wait docker does. Pants doesn’t
h
cc @curved-manchester-66006 who I think has the most experience with Docker plugin at this point
w
Can you pass them as run args?
s
I feel embarrassed to admit this but I've always struggled to understand how to write pants plugins. On the other hand, Claude was able to literally one shot it.
I'm trying out using registry storage. My strategy has been using branches as tags for cache and a fallback to {pants.hash} so that things built on a feature branch don't have a cache miss when merging to main.
w
🤷 no need to feel embarrassed to have difficulty writing a plugin in a build tool. If nothing else, might say what it says about our documentation on writing them. Also, Claude’s one-shotting is… ummm… not consistent, let’s say. So careful about that, your mileage may vary. But I’m still not fully understanding the problem you’re having here. You want multiple
cache-to
fields?
s
Im not proud of posting Claude code but
Copy code
"""Plugin to add extra_cache_to field to docker_image targets.

Pants models cache_to as a single dict (DictStringToStringField), but BuildKit
supports multiple --cache-to flags (since v0.11 / Buildx v0.10 / Docker 24.0,
moby/buildkit#3024). This plugin registers an additional list-of-dict field that
produces extra --cache-to flags, discovered automatically by get_build_options()
via the DockerBuildOptionFieldListOfMultiValueDictMixin inheritance.
"""

from pants.backend.docker.target_types import (
    DockerBuildKitOptionField,
    DockerBuildOptionFieldListOfMultiValueDictMixin,
    DockerImageTarget,
)
from pants.engine.target import ListOfDictStringToStringField


class DockerImageExtraCacheToField(
    DockerBuildOptionFieldListOfMultiValueDictMixin,
    ListOfDictStringToStringField,
    DockerBuildKitOptionField,
):
    alias = "extra_cache_to"
    docker_build_option = "--cache-to"
    default = ()
    help = "Additional --cache-to destinations for docker buildx build."


def rules():
    return [
        DockerImageTarget.register_plugin_field(DockerImageExtraCacheToField),
    ]
I feel like I should have been able to write that.
w
I mean, I’m not sure if anyone should write that specifically, but whatever. I guess what I’m asking is, why not use one of these options to do the same? https://www.pantsbuild.org/stable/reference/targets/docker_image#extra_build_args https://www.pantsbuild.org/stable/reference/targets/docker_image#extra_run_args
b
Be careful that the extra_build_args is quite misleading. The option does not allow to pass generic build option to it. The options allow you to parameterize your container builds (the
ARG
keyword in Dockerfiles) but not the options of the build itself (it is basically the
--build-arg
option). This pull request https://github.com/pantsbuild/pants/pull/23250 should hopefully allow you to do the things you want to do by allowing you to pass generic build options to docker/podman. In future, we should drop the weird hardcoded options in the docker_image target and only allow the generic build_extra_options field.
s