TLDR: how can I obtain the "full" path to the docker_image, either in the BUILD file, or in the pants.toml ? Details With the the registries configuration in the

pants.toml

IN the [docker] section, I have found the following variables available for the "repository" field

build_args, default_repository, directory, name, pants, parent_directory, tags, target_repository

It does not seem that there is a "full_directory" variable available. Context - I want to "auto" name the docker images - as

some-registry.internal/xyz/path/to/name:1.2.3

where fictionally, registry

address =some-registry.internal/xyz

path/to

is the root path in the mono repo. to the BUILD file and

name

is the default "name" in the

docker_image(name=...)

like ..

[docker.registries.our-internal-registry]
address = "some-registry.internal/xyz"
default = true
# build_args, default_repository, directory, name, pants, parent_directory, tags, target_repository
repository = "{full_directory}/{name}"

of course

full_directory

does not exist as a variable. I am aware of the repository parameter available in the

docker_image(... repository="somevaluehere", )

but I was hoping I would have either in the

BUILD

file, or the

pants.toml

a variable for the

full/path/to/build/

BUILD file

directory

is == to the name of the BUILD file parent_directory, as name suggests is one up.

There is a BUILD file function:

build_file_dir()

which returns a

pathlib.Path

that can be used in an f-string or similar. You’ll have to use a macro to set this automatically for every

docker_image

. It seems reasonable to have a pants.toml level substitution for the full path to be able to set the default more easily. Do you want to open a feature request or maybe a pull request? (Happy to provide pointers.)

im happy to make a PR - yes a pointer to where the other vars are defined.

These ones are docker specific. See

format_repository

in https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/docker/goals/package_image.py

so some nice context - I have a

BUILD

file is using the new 2.19

parametrize()

expansion. Very nice.

#
# Python base containers with TLS internal CA certs
#
docker_image(
  name="images-python",
  registries=["@acme-library-registry"],
  source="Dockerfile.python",
  dependencies=["common/pki:acme_tls_internal_CA_certs"],
  **parametrize("py310deb", repository="python", image_tags=["3.10-slim"],   extra_build_args=["BASE_IMAGE=python:3.10-slim","DIST_TYPE=debian:12"]),
  **parametrize("py311deb", repository="python", image_tags=["3.11-slim"],   extra_build_args=["BASE_IMAGE=python:3.11-slim","DIST_TYPE=debian:12"]),
  **parametrize("py312deb", repository="python", image_tags=["3.12-slim"],   extra_build_args=["BASE_IMAGE=python:3.12-slim","DIST_TYPE=debian:12"]),
  **parametrize("py310alpine", repository="python", image_tags=["3.10-alpine"], extra_build_args=["BASE_IMAGE=python:3.10-alpine", "DIST_TYPE=alpine:3"]),
  **parametrize("py311alpine", repository="python", image_tags=["3.11-alpine"], extra_build_args=["BASE_IMAGE=python:3.11-alpine", "DIST_TYPE=alpine:3"]),
  **parametrize("py312alpine", repository="python", image_tags=["3.12-alpine"], extra_build_args=["BASE_IMAGE=python:3.12-alpine", "DIST_TYPE=alpine:3"]),
)


#
# scratch based images
#
docker_image(
  name="images-alpine-and-scratch",
  registries=["@acme-library-registry"],
  source="Dockerfile.scratch",
  dependencies=["common/pki:acme_tls_internal_CA_certs"],
  **parametrize("busybox",                    repository="busybox",image_tags=["1.36"],        extra_build_args=["BASE_IMAGE=busybox:1.36"]),
  **parametrize("prom_prometheus",            repository="prom/prometheus",            image_tags=["v2.49.1"],     extra_build_args=["BASE_IMAGE=prom/prometheus:v2.49.1"]),
  **parametrize("prom_node_exporter",         repository="prom/node-exporter",         image_tags=["v1.7.0"],      extra_build_args=["BASE_IMAGE=prom/node-exporter:v1.7.0"]),
  **parametrize("prom_alertmanager",          repository="prom/alertmanager",          image_tags=["v0.26.0"],     extra_build_args=["BASE_IMAGE=prom/alertmanager:v0.26.0"]),
  **parametrize("gcr_io_cadvisor_cadvisor",   repository="<http://gcr.io/cadvisor/cadvisor|gcr.io/cadvisor/cadvisor>",   image_tags=["v0.47.2"],     extra_build_args=["BASE_IMAGE=<http://gcr.io/cadvisor/cadvisor:v0.47.2%22|gcr.io/cadvisor/cadvisor:v0.47.2">]),
  **parametrize("grafana_grafana_enterprise", repository="grafana/grafana-enterprise", image_tags=["10.3.1"],      extra_build_args=["BASE_IAGE=grafana/grafana-enterprise:10.3.1"]),
  **parametrize("bitnami_minio",              repository="bitnami/minio",              image_tags=["2024.2.9"],    extra_build_args=["BASE_IMAGE=bitnami/minio:2024.2.9"]),
)

Maybe

build_file_path

mimicking the function?

perfect

I'm surprised

directory

is the name of the BUILD file - never used it, but from the docs:

The default placeholders are:

{directory}: The directory the docker_image's BUILD file is in.

Wondering if it's a bug.

I made a mistake in my description

some/path/to/parent/folder/BUILD
               |      |         
               |      `---------- {directory} == "folder"        
               `----------------- {parent_directory} == "parent"

there is no access to "some/path/to"