https://kotlinlang.org logo
#server
Title
# server
m

Mod

12/03/2023, 1:01 PM
Hello guys, I have a ktor app and I'm using application.conf for project configuration and I'm reading the environment variables directly inside application.conf is there a way to define .env file and put all the environment variables in it and still read the variables inside the application.conf
c

Cies

12/04/2023, 9:17 AM
For this purpose I use this:
Copy code
#!/bin/sh
# Filename:      dotenv
# Purpose:       import environment variables from .env file and make available to other commands
# Authors:       Jason Leung (<mailto:jason@madcoda.com|jason@madcoda.com>), multiple contributors (<https://github.com/madcoda/dotenv-shell/graphs/contributors>)
# Bug-Reports:   see <https://github.com/madcoda/dotenv-shell/issues>
# License:       This file is licensed under the MIT License (MIT).
################################################################################


set -e

log_verbose() {
        if [ "$VERBOSE" = 1 ]; then
                echo "[dotenv.sh] $1" >&2
        fi
}

is_set() {
        eval val=\""\$$1"\"
        if [ -z "$(eval "echo \$$1")" ]; then
                return 1
        else
                return 0
        fi
}

is_comment() {
        case "$1" in
        \#*)
                log_verbose "Skip: $1"
                return 0
                ;;
        esac
        return 1
}

is_blank() {
        case "$1" in
        '')
                log_verbose "Skip: $1"
                return 0
                ;;
        esac
        return 1
}

export_envs() {
        while IFS='=' read -r key temp || [ -n "$key" ]; do
                if is_comment "$key"; then
                        continue
                fi

                if is_blank "$key"; then
                        continue
                fi

        value=$(eval echo "$temp")
        eval export "$key='$value'";
        done < $1
}

# inject any defaults into the shell
if is_set "DOTENV_DEFAULT"; then
        log_verbose "Setting defaults via $DOTENV_DEFAULT"
        if [ -f "$DOTENV_DEFAULT" ]; then
                export_envs "$DOTENV_DEFAULT"
        else
                echo '$DOTENV_DEFAULT file not found'
        fi
fi

if is_set "DOTENV_FILE"; then
        log_verbose "Reading from $DOTENV_FILE"
else
        DOTENV_FILE=".env"
fi

# inject .env configs into the shell
if [ -f "$DOTENV_FILE" ]; then
        export_envs "$DOTENV_FILE"
else
        echo "$DOTENV_FILE file not found"
fi


# then run whatever commands you like
if [ $# -gt 0 ]; then
        exec "$@"
fi
DOTENV_FILE=conf/local.env JAVA_TOOL_OPTIONS="-Dlog4j_rootLogger=INFO,Console,Rolling" ./conf/dotenv java -jar my_app.jar
On production we do docker so env vars go by a different mechanism. The
EnvFile
plugin in IDEA is also very helpful when using this.
c

CLOVIS

12/05/2023, 1:12 PM
Yes, you can put all your variables with the keyword
export
in your file, then use the
source
command:
Copy code
# vars.env
export foo=bar
export other=3
Then just
Copy code
# loads the environment variables
source vars.env
after that, you can execute your server normally.
c

Cies

12/05/2023, 2:06 PM
The advantage of my approach is that you can use a
.env
file, that is also recognized by the
EnvFile
plugin in IntelliJ.
c

CLOVIS

12/05/2023, 2:17 PM
Mine is recognized by the Shell script support plugin 🙂
c

Cies

12/05/2023, 3:50 PM
Did not even know that existed! Thanks.
1
question: how to make sure a shell script is run as part of a run configuration (and in a way that the run config get the env vars)?
c

CLOVIS

12/05/2023, 4:29 PM
Ah, if you want to do this then you will probably have to use the EnvFile plugin. I don't think vanilla IDEA supports this. You could have Gradle load the file and create the environment variables itself, but honestly at this point, it would be simpler to use something like https://github.com/sksamuel/hoplite so your server can read both environment variables and .properties files
c

Cies

12/05/2023, 4:31 PM
nice suggestions, thanks once again. not sure it's worth the effort at this point, but I'll make a comment in our config code to refer to this project in case we ever going/need to renovate that part of the codebase