Support system variables?
Opened this issue · 9 comments
I didn't use the template because this issue is more a question.
Do you plan to integrate environment variables?
I mean if you have a key api_key in your properties file but in the meantime,
you have an environment variable with the same name api_key.
Should the env var override the variable in the properties file?
That will allow you to pass variables while building your app in a CI setup.
Even better you can configure your CI to build multiple environments with different app names, backend URLs, etc...
@Karumi/commanders I'm not sure if this feature would be helpful right now. Multiple environments could be configured using flavors or build types as described in the official documentation. Before thinking about supporting config override by env vars, I'd first ensure we can use flavors and build configs properly. What do you think guys?
I think it is helpful because we want to have those variables even in iOS and Javascript, the idea is to have the same BuildConfig we have in Android but for common source code and every client if they need it for some reason.
I don't think we need to do something with environment variables because they are defined in runtime, and we want to add properties in build time. We can connect Android app client flavors to Hagu Build environments and if you are running staging flavors / build type you can have a staging.properties in common library with the defined variables. I don't know yet how iOS targets works, but it'll be the same, at least in Gradle we can know if iOS compile in debug or production, then I think the user can add more targets like staging. 👍
Doing it in this way, you don't need to duplicate keys for the common library module, which is the main idea.
Does it make sense of what I said?
Using environment variables could be handy for the scenarios @geftimov suggested.
I think we can close this one, I will create a fork with the following functionality. Thanks for the discussion.
I reopen the issue because it could be interesting to create a way where you can create BuildConfig from env variables for Continuous Integration / mixing secrets with hardcoded values.
My proposal allows gradle.properties file to use env variables in this way:
From the example on README, something like that
api_key = ${API_KEY} //API_KEY its an environment variable
number_key = 11 //allow mixing
If you want to add this feature @geftimov feel free to create a fork and make PR, if not, I'll add it at some point, thank you!!
@geftimov I'm working on this issue, finally, the first approximation to resolve this issue, You'll be able to select different configuration profiles for debugging, production, ci, etc.
With adding a Gradle property to select the profile you want to use in this way:
- You have to create different property files with variables or secret keys:
debug.properties
release.properties
ci.properties
- Then you'll be able to switch depending on the Gradle property like, in this example, I'm choosing to compile with CI variables:
./gradlew build -Pprofile=ci
In the next iteration, I'll in the CI or Release profiles you'll be able to add env vars to your properties in this way:
api_key = ${API_KEY} //API_KEY its an environment variable
I hope this new functionality will help :D
This is great thanks.
I was thinking is there a way for the env vars to override the property altogether?
I will try to show an example :
Without env vars
gradle.properties
api_key = "some_api_key"
code
println(HaguConfig.API_KEY) //output: some_api_key
Without env vars
env vars
api_key = "env_api_key"
gradle.properties
api_key = "some_api_key"
code
println(HaguConfig.API_KEY) //output: env_api_key
That is for the second iteration, and not sure if I should do that because having separated profiles, you will see explicitly the env vars used in your application. At the code level, it doesn't matter how I get the env vars, so, let me think about it, anyway, the feature will be done!
I'm going to open the PR in a few hours to use different profiles! 👏
Great job !