not able to source a shell / bash file within the .env file-CodePudding

I tried so many key words:

use source
nothing in front of the path
use

# set -a # automatically export all variables
'./../private/some-cred.sh'
# set  a

None of them allow me to import some private creds into the .env file that will be ran by fastlane Dotenv.overload './config/.env.qa'

Current files:

./config/.env.qa

# source './../private/fastlane-cred.sh'
# APPLE_API_KEY_ID=$APPLE_API_KEY_ID_PRIVATE

./private/some-cred.sh

export APPLE_API_KEY_ID_PRIVATE="AAA"

When this setup got loaded into bitrise (which is in ./ios/) via Dotenv.overload './config/.env.qa'

The value will be considered as empty.

Any idea what else I should do, in order to allow me to load some variables from a file into .env properly so its recognized?

NOTE: path is correct. because I had a file ref defined within .env file and it was loaded in the bitrise ENV var correctly. but not for variables.

CodePudding user response：

What is important to know about the "dotenv" paradigm is that the various "dotenv" implementations are mimicking a shell environment instead of actually being a shell environment. As they are run from inside the application, written in a non-shell language - it is far too late at this point to use the shell to setup environment variables. The "dotenv" libraries aren't even actually changing the process's environment - they just use the runtime's API to store data in such a way that other code that uses the runtime's environment access API will see it as if it's coming from the environment.

The fastlane system uses the dotenv gem which uses an internal parser (based on regular expressions) to parse a file that looks like a shell file (containing only variable assignment) but isn't an actual shell file. Everything there that doesn't look like a naive shell variable assignment is ignored - the dotenv file isn't actually a shell script and isn't treated like a shell script, so you can't put shell scripting commands in it and expect it to work.

If you really want to use shell scripting to setup your environment - then use a wrapper shell script to start your environment (or a Makefile) instead of using the application's internal "dotenv" support - which as I explained above, isn't actually a shell script.