request: support more of the normal jsonnet input flags

[ghostsquad]

This is a request to have Tanka support some of the other standard flags for use with jsonnet:

--tla-code
--tla-code-file

--tla-str
--tla-str-file

--ext-str-file
--ext-code-file

-J / --jpath

Also, the naming of these should likely be standard between TK and Jsonnet for ease of discovery. I filed a separate issue for that here: #354

[issue-label-bot]

Issue-Label Bot is automatically applying the label kind/feature to this issue, with a confidence of 0.99. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[sh0rez]

TLAs have been added by #340. This also changed the flags to match those of jsonnet.

Current flags:

--tla-code
--tla-str

--ext-code
--ext-str

Because Tanka has the model of ranked import paths (https://tanka.dev/libraries/import-paths), I'm not sure if allowing arbitrary jpaths is a good thing here.

Generally vendor, lib and the local environments directory should allow enough flexibility to layout any kind of library hierarchy. It also makes it easy for newcomers to Tanka / developers adopting existing projects to quickly find libraries, because of muscle memory.

WDYT?

[ghostsquad]

although I would normally agree. If I'm working only on kubernetes, this directory structure makes sense. But I'm using jsonnet for a lot more than that, and as such, I'm actually importing files outside of my kubernetes/environments folder.

I have a global "config", that's used to hold values that are common among a variety of generated configuration files.

For now, I'm simply forced to do ugly relative imports, of which, some start with ../../../../

[davidovich]

I think this is a valid ask, and Tanka could enforce its preferred order, and append the user defined -J paths.

I have a shared base config for CI-CD, and this would allow inclusion even if not in the intended Tanka import order.

[sh0rez]

TLAs and extVars are implemented, using the same flags as Jsonnet does.

JPATH has its own tracking issue: #365

Closing as there is nothing to do here anymore :)

[lukasmrtvy]

@sh0rez but --ext-code-file is not implemented..., seems there isnt a way how to dynamically include file, for example use case with sops:

sops exec-file secrets.enc.yaml 'tk show . --ext-code-file secrets={}'

nor

local secrets = import std.extVar('secrets_path'));

sops exec-file secrets.enc.yaml 'tk show . --ext-str secrets_path={}'

can not work.. any workaround?

sops exec-file - execute a command with the decrypted contents as a temporary file

thanks

[davidovich]

@lukasmrtvy Assuming you have a tanka top level function that takes a secrets object in parameter, I am able to inject secrets in Tanka in this manner:

sops exec-file mySecretFile.enc.json 'tk apply --tla-code secrets={secret: import \"{}\"} environment'

Hope that helps.

[danihodovic]

--ext-code-file would be useful for injecting secrets from temporary files.

The following works for top level variables

sops exec-file ../terraform/staging/secrets.enc.yaml \
	"tk apply environments/staging --ext-code secrets='import \"{}\"'" \
	--output-type=json