Allow overwriting of values in .env based on flavor

[lugg]

Allow overwriting of values in .env based on flavor

[barbogast]

I think I understand better:

If I run react-native run-android --variant staging the correct environment file is loaded. But then the command exits with the error Task 'installStaging' is ambiguous in root project 'my_app'.

When I run react-native run-android --variant stagingDebug the command runs successful, but with the default .env file.

So it looks like react-native run --variant needs flavor + buildType which is not understood by react-native-config.

[hdchan]

Follow up: the patch in #52 also does not work in Buddy Build when building multiple variants. They are running one command like ./gradlew assembleReleaseStaging assembleReleaseProduction to build multiple variants in one pass, but this only executes the dotenv.gradle code once for both builds. It ends up taking the staging settings for both builds.

@chase-seibert i need this as well. Not sure if or when Buddy Build will implement separate gradle runs for each variant.

[pedro]

oh, and interesting take on how we could integrate this better form inside the android Gradle config.

Guess I ended up going this way because react-native run-android doesn't seem to take an environment, although maybe there's something you can pass there to get Gradle to figure out what environment it should build..?

[caseyg1204]

Does anyone have a work around for this on Buddy Build?

[pedro]

Hey! Sorry I missed this, wasn't set to watch the project for some weird reason.

I personally use a single .env file per env to keep things simpler and easier to reason (eg: there's just .env.sample, use that to generate any other, etc). I realize this is cumbersome for certain projects/styles though, so down to experiment with alternatives.

So – if I got this right – we'd keep reading from .env in the normal case, but when ENVFILE is set then we'd read from that file and fill in missing values with whatever is in .env?

[freakinruben]

I'm currently using a modified dotenv.gradle in which I use:

def envFile = project.hasProperty('envFile') ? project.get('envFile').toLowerCase() : ".env.debug"

This allows the envFile prop to be set when calling gradle with a different buildType, e.g.:
./gradlew -PenvFile=.env.production assembleReleaseProduction

I've tried to integrate into

android {
    buildTypes {
        debug {
...
        }
        releaseProduction {
...
        }
    }
}

but I couldn't figure out how, so if anyone has a more elegant solution, I'm curious to learn about it :-)

[chase-seibert]

Seconding the proposal to support defining which env is loaded from buildTypes. I'm using Build Buddy to create builds, and it cannot set different environment variables per build type.

[chase-seibert]

Follow up: the patch in #52 also does not work in Buddy Build when building multiple variants. They are running one command like ./gradlew assembleReleaseStaging assembleReleaseProduction to build multiple variants in one pass, but this only executes the dotenv.gradle code once for both builds. It ends up taking the staging settings for both builds.

[barbogast]

@pedro

... because react-native run-android doesn't seem to take an environment...

There is a --variant switch for run-android, but react-native-config always uses the .dev file.

I'm still confused but to me it looks like ./gradlew assembleRelease already builds the different flavors using the correct env-files.

[hdchan]

I created a pull request to address this: #180 @caseyg1204