feat: Allow entrypoints other than main.jsonnet when searching for environments

[sabeechen]

Description

When using inline environments, some tk commands produce empty results when using an entrypoint whose filename is anything other than main.jsonnet.

Example

You can reproduce the behavior by creating a simple project with an inline environments having two entrypoint files:

main.jsonnet

{
  apiVersion: 'tanka.dev/v1alpha1',
  kind: 'Environment',
  metadata: {
    name: 'main',
  },
  spec: {
    apiServer: 'https://localhost',
    namespace: 'default',
  },
  data: {
    apiVersion: 'v1',
    kind: 'ConfigMap',
    metadata: { name: 'config' },
  },
}

other.jsonnet

import 'main.jsonnet'

With this setup running the commands:

tk env list main.jsonnet
tk export export-dir main.jsonnet --recursive

Will produce the expected result, either listing the environment or exporting a ConfigMap manifest. However running:

tk env list other.jsonnet
tk export export-dir other.jsonnet --recursive

will not print any environments and exports nothing. Running tk export export-dir other.jsonnet --name main will, however, export the manifests for the environment. This behavior feels inconsistent. I'm not sure if supporting this should be considered a feature or bug.

Rationale

My organization's tanka-based stack makes heavy use of inline environments to generate its manifests. In the never-ending search for "the cleanest way to do things" we sometimes find it convenient to create two entrypoints for a project where one selectively uses manifests from the other. But only one can be named main.jsonnet, which has made building automated tooling that depends on using env list or --recursive to find environments troublesome. Admittedly, this may be a niche use case and it could be solved using external variables.

Solution

I've modified find.go such that if the requested search path for environments is exactly the name of the found file, then it is considered a mainfile. this seems to resolve the inconsistency in behavior for inline environments and I struggle to think of a way it could cause problems.

[zerok]

Thanks for giving this one a try 🙂 So far I also cannot really think of any negative side-effects for existing cases. The default entrypoint is also used for the importers command. If I'm not mistaken then your change should probably also be somehow integrated there. But perhaps I'm also confusing the use-cases these two...