A Helm named template needs two inputs, but `include` takes one argument — how do you pass both?

## The constraint Calling a named template — with `include` or with the `template` action — passes exactly one value, and that value becomes dot inside the partial. There is no parameter list, no keyword arguments, and no way to add a second positional argument. Any partial that needs more than one input therefore needs its caller to bundle those inputs into a single value. ## The dict idiom The standard bundle is a map built by the `dict` function, which takes alternating keys and values: ``` {{- include "fraud-scoring.probe" (dict "ctx" $ "port" .Values.service.port "delay" 7) }} ``` The parentheses matter: they make the whole `dict` call one expression, evaluated first, so `include` sees a single argument. Inside the partial, dot is that map, and each input is read by key — `.port`, `.delay`. A missing key is simply absent, so `{{ .delay | default 5 }}` inside the partial is the cheap way to make a parameter optional. ## Why the root context usually rides along Rebinding dot to the dict has a consequence that surprises people: the render context is gone. `.Values`, `.Release`, `.Chart` and `.Capabilities` are all fields of the context that the manifest was rendering with, and the partial no longer holds that context — it holds your two-key map. `$` is no rescue either: it is bound to the data value the current template execution started with, which for an included partial is the argument you passed, so `$` and dot are the same dict. That is why almost every real chart passes the context in as one of the keys, conventionally named `ctx`, `top` or `root`: ``` {{- include "fraud-scoring.probe" (dict "ctx" $ "port" 8443) }} ``` and inside the partial writes `{{ .ctx.Release.Name }}` or `{{ .ctx.Values.image.tag }}` alongside `{{ .port }}`. Pick one key name and use it across the whole chart; a chart where half the partials say `ctx` and half say `top` produces exactly the sort of empty render that costs an afternoon. ## Building the dict from existing data `dict` is not the only way to make the bundle. A partial that mostly wants an existing map with one extra field can be handed a merged map — merge the caller's small dict over a defaults dict — and a partial that genuinely wants a list can be given one with `list`. Two habits are worth avoiding. First, do not build a positional list and index into it inside the partial (`index . 0`, `index . 1`): the call site stops being readable and reordering breaks silently. Second, do not mutate the context: `set` on a map derived from `.Values` changes shared data for every later template in the render, which produces order-dependent output that is miserable to debug. Build a fresh dict instead. ## Variables do not cross the boundary Another instinct is to set a variable in the caller and read it in the partial. Template variables are lexically scoped to the template that declares them, so `$port` defined in the Deployment is invisible inside the partial; the partial sees only its argument. The same applies in the other direction: a variable assigned inside the partial does not leak back. The single argument really is the entire interface, which is a feature — it makes a partial testable by rendering it with a known dict. ## Designing the partial's interface Because the interface is one map, it pays to treat it like a function signature. Document the keys the partial expects in a comment above the `define`. Validate the ones that must be present, so a caller that forgets a key gets a clear failure rather than a Deployment with an empty port. Keep the key set small: a partial taking eight keys is usually two partials, or a partial that should have been given the context and read the values itself. A useful rule of thumb: if the partial is generic — a probe block, a resource block, a name truncator — take explicit keys plus `ctx`. If the partial is really "the labels for this chart", take plain `.` and read `.Values` and `.Release` directly; wrapping that in a dict adds ceremony and nothing else. ## Reading a failure When a dict-taking partial renders an empty or half-built block, the diagnosis is almost always one of three things: the caller passed `.` where the partial expects a dict, so every key lookup is missing; the caller passed a dict where the partial expects the context, so `.Values` is missing; or a key name is misspelled on one side. Rendering the chart and reading the block that came out — rather than the template — tells you which, because a missing key renders as nothing at all rather than as an error.