Go os.LookupEnv is not working as expected

[franck-boullier]

Overview:

We need variables that are stored in the AWS parameter store.
Getting these variables can take a lot of time up to the point where some tests are timing out.
The solution is to declare these variables as environment variables <-- avoid costly AWS Parameter store queries.

The aws.env script:

In PR #16 we have created a bash script aws.env. That script's ONLY objective is to optimize our code --> avoid querying the AWS parameter store again and again.

See how it work in the Travis CI build of the unit repo (WIP)

You can see that the environment variables are correctly set in the OS:

The problem:

We are using the go module/package os and the function os.LookupEnv in our main.go file (see an example here).

Expected result:

Since the Environment variable (ex: BUGZILLA_DB_USER) has been set, there should be NO NEED for a call to the AWS parameter store.
The INFO on the Travis CI build should be something like
"BUGZILLA_DB_USER overridden by local env: xxxx"

Actual result:

The message in the travis build is
INFO[0002] BUGZILLA_DB_USER is unset as an environment variable. The value is **bugzilla** in AWS Parameter store

This tells us that the main.go script had to query AWS to get that variable <-- NOT GOOD

See screenshot from the Travis CI build

Context:

In the current PR #16 to facilitate and speed up debugging, we have temporarily imported some of the code that will eventually be part of the uneet/env repo.
The key functions we need and that are supposed to be in the uneet/env repo are:

• BugzillaDSN
• New <-- this has been renamed to NewConfig in the PR Merge Une-T INS improvements - remove hardcoded values that should be in variables #16 to avoid conflicts.

[kaihendry]

Where are you intending to optimise these parameter store lookups?

• when the function is run?
• on CI?
• on go test? Can you show a build where this is slow?

When the function is run probably makes the most sense and you can set that with up env. But then you would need to build this into the deployment process.

[franck-boullier]

Where are you intending to optimize these parameter store lookups?

Ideally each time the function has to run (but I don't know how to do that yet, still experimenting so any idea/suggestion is welcomed 😅

[franck-boullier]

The solution was to declare ./aws.env as the source for the variables in the .travis.yml file.

See b156eea