Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support system variables? #6

Open
geftimov opened this issue Sep 23, 2019 · 9 comments
Open

Support system variables? #6

geftimov opened this issue Sep 23, 2019 · 9 comments
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@geftimov
Copy link

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...

@tonilopezmr tonilopezmr added enhancement New feature or request help wanted Extra attention is needed labels Sep 23, 2019
@pedrovgs pedrovgs added the question Further information is requested label Oct 4, 2019
@pedrovgs
Copy link
Contributor

pedrovgs commented Oct 4, 2019

@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?

@pedrovgs pedrovgs changed the title System variables Support system variables? Oct 4, 2019
@tonilopezmr
Copy link
Contributor

tonilopezmr commented Oct 4, 2019

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?

@pedrovgs
Copy link
Contributor

pedrovgs commented Oct 4, 2019

Using environment variables could be handy for the scenarios @geftimov suggested.

@geftimov
Copy link
Author

I think we can close this one, I will create a fork with the following functionality. Thanks for the discussion.

@tonilopezmr
Copy link
Contributor

tonilopezmr commented Oct 24, 2019

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!!

@tonilopezmr tonilopezmr reopened this Oct 24, 2019
@tonilopezmr
Copy link
Contributor

@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

@geftimov
Copy link
Author

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

@tonilopezmr
Copy link
Contributor

tonilopezmr commented Apr 22, 2020

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! 👏

@geftimov
Copy link
Author

Great job !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants