👋 - I'm trying to configure helm deploys to a local kind k8s cluster. I've managed to add a field to the

helm_deployment

target, and while the field itself is added to the target, i am not sure how to make the underlying target use that field. more concretely, I'm adding

kubeconfig

as a arg like:

# file pants-plugins/internal/helm_args/register.py
from pants.backend.helm.target_types import HelmDeploymentTarget
from pants.engine.target import StringField

class KubeconfigFileField(StringField):
    alias = "kubeconfig"
    default = "$HOME/.kube/kind-config"
    help = "which config file to use"

def rules():
    return [HelmDeploymentTarget.register_plugin_field(KubeconfigFileField)]

and when running:

PANTS_HELM_ARGS="--kubeconfig=$HOME/.kube/kind-config"  pants experimental-deploy <helm_target>

it works as expected; when running

pants experimental-deploy model_builder/infra/mzai:local  --keep-sandboxes=always

it doesn't. a few questions: • how do i see the command that pants is using to run helm?

-ldebug

doesn't seem to work? • is this the expected use for extending targets?

For your questions: 1. I'd expect either

-ldebug

or looking at the

__run.sh

command in the relevant sandbox to be two mechanisms to see the underlying command. 2. For extending targets: a. As you observe, adding a field to a target doesn't automatically mean the rules that interact with the target (like the deploy ones) will use it. b. The usual use case is something like the black Python formatter: that backend adds a

skip_black

field to

python_...

targets, and the formatting rules in the black backend itself read that field, while "base" python backend doesn't need to care about it. Maybe @careful-address-89803 has some advice about helm specifically?

yeah, i could see a better solution to actually add the new field via a PR or create a new target. as an aside, are people setting kube and helm contexts / configs outside of pants? i want to be able to wrap all of this in an Environment or something like that, perhaps

I looked into this a bit. Unfortunately we're not really set up to add args or envvars for command execution in an extensible way.

gotcha, was hoping to manage more of that from within pants itself