Hello All:
Within the workflow developer, I’m wondering about the use of the “Get ENV variable” function that appears on the functions list dropdown.
Is this intended to allow one to read OS-level environment variables (e.g., similar to NodeJS process.env.VARNAME)? If so, is there something special that needs to be set with respect to the key field? Can someone provide an example of how to setup the function and use its output?
Thanks!
Yes, you can use that function to get a value from a corresponding key inside the .env file in your host directory.
For example, if you had a VERSION=2023.3.8 key/value in the .env file you can use the workflow below (unzip and import) to log it.
Get ENV.zip (806 Bytes)
Thanks for providing this sample! I was able to import and run the sample and recreate a working version using the ENV variable VERSION!
Is it possible to access other environment variables, though? When I connect to a shell in the docker container I can see many more variables when I run env | sort in the shell. But in the workflow, everything other than VERSION as the function parameter seems to return <nil> even though I see the environment variable in the shell.
In terms of use case, I’m really trying to solve for how to best inject secrets into workflows (e.g., if I need to call an external API that requires a specific bearer auth). I thought just adding a new ENV variable when I launched the docker container would be a reasonable way to go, but maybe it won’t work if Corteza can’t access all the container’s ENV variables.
I know there’s a guide on Dynamic Configuration with a separate module. However, I wonder if that’s the most secure way to store the sensitive data?
I really don’t want to take a step back toward Corredor and server-side scripting, but I suppose that’s workable as a last resort if we really have to use an ENV.
We exposed a limited set of variables.
For now, if you want to bring in secrets, I’d suggest you use the new module (you can hide the secrets behind RBAC if you need).
As a side note, it would make sense to expand this to include (a subset) of env variables. We’ll discuss it and tweak it if we see fit.