#Hey guys, how can I read environment variables, from a caller zenith module (through code)?

1 messages · Page 1 of 1 (latest)

slow shuttle
#

About managing environment variables in a module, Am I correct to understand that currently, having something like os.Getenv("my_env_var_already_exported") from a zenith module will work to read an already exported environment variable?
https://github.com/dagger/dagger/issues/6112#issuecomment-1813537423
The reason why I'm asking is that in this module https://github.com/Excoriate/daggerverse/blob/0c2495c0ca1fecce366734e0eb6a97c8ceaf3adb/iac-terragrunt/main.go#L51 I'm planning to use it from another module (a higher-level sort of CI module from where I'm planning to read some environment variables (from its code) by using, for example os.Getenv as I normally would do in the 'old' dagger way.

GitHub

Right now callers can pass their environment variables to modules by just reading them and setting them to function arg values, e.g. w/ the cli: dagger call my-function --some-arg $SOME_ARG_VALUE T...

GitHub

A collection of Dagger modules powered by Dagger. Contribute to Excoriate/daggerverse development by creating an account on GitHub.

spark adder
#

Am I correct to understand that currently, having something like os.Getenv("my_env_var_already_exported") from a zenith module will work to read an already exported environment variable?

No, it won't. Beacuse modules run in containers. os.Getenv still works there, but it's not from your host and we don't currently have config for adding them to the runtime container (the one that runs the module).

Ideally env vars should be passed as values to function arguments and let the CLI get them from the host instead. We're still trying to figure out/design some conveniences around this, preferably around the CLI.

slow shuttle
#

Okay. It means that it's not possible to pass —through code, not through the CLI— exported environment variables from the host in a (zenith) caller module to another one that's installed and used from that module; which IMO it's a bit of a limitation.
From the caller module standpoint, it means that in order to receive this host environment variables, it should in turn have a function on its side to receive those environment variables from the CLI when it's invoked (E.g.: from a CI environment, that's how I'm thinking it's going to work) and passing them to the caller module's function.
is there any other alternative?

spark adder
#

We plan on supporting calling modules from non-module code. It's a codegen issue; you can do it today with a query, just not with the SDK's client. This way you'd be able to use the SDK like today to gather your env vars and pass to the module using code. I hate to say this, but you can also wrap a script to do the same for passing arguments to the CLI. Can also be a go program that execs the dagger CLI though.

As for other alternatives, as I said, we're currently discussing what's the best design here in the Make passing caller environment variables to modules more seamless issue. If you have any suggestions, we appreciate your feedback in that issue! 🙏

GitHub

Right now callers can pass their environment variables to modules by just reading them and setting them to function arg values, e.g. w/ the cli: dagger call my-function --some-arg $SOME_ARG_VALUE T...