Add `image_deps` support to `kubectl_build`

[milas]

Kristinn asked in Slack:

Has anyone gotten kubectl_build to work with dependencies on other images expressed in the tiltfile?

We do support image_deps in the underlying custom_build now, but it hasn't been wired up for this extension.

Unfortunately, it's not as simple as passing through the argument, as the actual build command needs to understand how to consume the references that Tilt passes as TILT_IMAGE_i environment variables (where i is the index in image_deps arg).

Proposal

In practice, I can't see any way you'd use an image dependency (with the kubectl_build extension specifically) other than in an ARG.

I think a new parameter to kubectl_build could handle this -> image_deps_to_build_args: Dict[str, str] = None

kubectl_build('my-base-image', ...)

kubectl_build(
  'my-app-image',
  ...,
  image_deps_to_build_args={
    'my-base-image': 'BASE_IMAGE'
  }
)

ARG BASE_IMAGE
FROM BASE_IMAGE

...

Then in kubectl_build:

i = 0
for build_arg in image-deps_to_build_args.values():
  command += ['--build-arg', '{build_arg}=TILT_IMAGE_{i}'.format(build_arg=build_arg, i=i)]
  i += 1

custom_build(..., image_deps=[k for k in image_deps_to_build_args])

I'm slightly conflicted about using a dict given the ordering importance, but it's much more ergonomic than a list of tuples, and from Starlark dict reference:

Dictionaries are iterable; iteration yields the sequence of keys in insertion order

[milas]

@nicks wdyt about this proposal? I both want to make sure I didn't miss any subtlety around image_deps wrt custom_build and sanity check that this is a reasonable approach for custom build extensions

[nicks]

fwiw, I did this as two lists in helm_resource for a few reasons

• trying to keep the tiltfile functions "closer" to the underlying api object
• image_deps in the underlying api is a list
• underlying api conventions generally discourage maps (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-of-named-subobjects-preferred-over-maps)
• was expecting we might need to change image_keys later

i definitely could make the case either way, but would feel weird if half the apis used the list approach and half used dicts

[milas]

That makes sense! Having image_keys be build arg key names is straightforward enough