Is there a way to pass an environment variable to a

docker_image

target as a secret? https://www.pantsbuild.org/stable/reference/targets/docker_image#secrets seems to suggest that I must have my secret in a file and pass the filepath, but I'd like to do something like

secrets={id: env(ARTIFACTORY_PASSWORD)}

the underlying code seems to only support file paths: https://github.com/pantsbuild/pants/blob/fdfd8d2a2ff985f8b8bae869b5467f6e48f65888/src/python/pants/backend/docker/target_types.py#L464-L477 Do you have a particular

docker build --secret=...

syntax that supports this in mind? If so, Pants could definitely support it, but if Docker only supports file paths, it makes less sense for Pants to layer on extra functionality (IMO). One approach might be synthesizing a code-genned file, e.g.

shell_command(name="artifactory-password-file", command="echo $ARTIFACTORY_PASSWORD > artifactory-password", extra_env_vars=ARTIFACTORY_PASSWORD )

(https://www.pantsbuild.org/stable/reference/targets/shell_command)

yeah, I'm trying to convert an existing docker build setup that uses

docker build --secret id=artifactory_user,env=ARTIFACTORY_USER

ah, cool, sounds like something pants can support! Are you interested in contributing it?

Not sure if its above my level... I'm trying to write a plugin to run kubescore against helm charts right now and its a bit rough haha. I'd be interested to look into it for sure though

okay, I think that linked code above is the core that needs to change. The process might be: 1. File a feature-request issue 2. Decide the syntax for indicating a file vs. an env var secret in a BUILD file 3. Change

option_values

in that code linked to emit

env=...

instead of

src=..

when appropriate 4. Somehow ensure the env vars are provided to the docker build invocation 5. Expand the test to cover this case too (https://github.com/pantsbuild/pants/blob/fdfd8d2a2ff985f8b8bae869b5467f6e48f65888/src/python/pants/backend/docker/goals/package_image_test.py#L[…]92)

I'll look into it

For syntax, ideas might be: 1. URL scheme-style

env:NAME

, e.g.

secrets={"id": "env:ARTIFACTORY_USER"}

◦ (We could then make files align (with a deprecation warning), so one has to write

secrets={"id": "file:./path/to/file"}

(for instance) 2. mimic the underlying syntax like

env=NAME

, e.g.

secrets={"id": "env=ARTIFACTORY_USER"}

◦ (as above, could make files align) 3. a new option, e.g.

secrets_from_env={"id": "ARTIFACTORY_USER"}

a. (and rename the existing

secrets

to

secrets_from_file

) ◦ (this version could even support

secrets_from_env={"ARTIFACTORY_USER": None}

to pass

--secrets id=ARTIFACTORY_USER

which apparently implicit reads the

id

as a env var) I'm mildly inclined to the last one