fastlane integration about react-native-ultimate-config

[berdyshev]

for the moment I've found a solution as

require 'dotenv'


lane :beta do |options|
    envFileName = ".env.#{options[:env] ? options[:env] : 'dev'}"
    sh("yarn", "rnuc", envFileName)
    Dotenv.load("../../#{envFileName}")
    puts "Building app: #{ENV['APP_NAME']}"
    .....
end

and then call it as fastlane ios beta env:prod

[maxkomarychev]

hi @berdyshev I didn't plan on adding this kind of integration, however this looks interesting.

do you keep fastlane folder per ios/android project? do you expect config of react-native-ultimate-config to be primary source of truth?

can you share a little more about what is your set up and what is the expect usage scenarios?

thanks.

[berdyshev]

Fastlane is configured separately for ios/android projects.
yes, I want env files to be source of truth so I can easily switch between environments.
I use react-native-firebase and I have to use different firebase projects per env (dev/prod). that's why I have 2 different schemes in ios project and 2 different build types in android. and I want to be able to switch between schemes/build types within fastlane config as well.

[maxkomarychev]

@berdyshev what kind of integration do you use for this lib? via rnuc cli or implicit via flavors/schemes?

[berdyshev]

sorry, what integration do you mean?
Now I'm using rnuc to manage the env parameters, like app name, splash screen name for iOS (they are different for some cases, and for android it's all configured via build types and different resources) etc. Also, there is in the plan to use different bundle ids per env.

[maxkomarychev]

You mentioned you are using multiple schemes/flavors in native projects.
Do you use yarn rnuc in CLI to inject the environment as mentioned in quickstart or scheme and flavor based integration?

[maxkomarychev]

ok I believe I got the full scope now. well, as a short term solution I can offer a hook mechanism for rnuc CLI so that you will be able to have a callback that would intercept invocation of rnuc and within which you will be able to codegenerate env files for fastlane like so:

module.exports = function(env_path, env_data) {
  fs.writeFileSync("./ios/.env", env_data) // should rather use dotenv here
}

so that by doing yarn rnuc my_env_file fastlane's default .env will be initialized with data of rnuc environment

makes sense?

[berdyshev]

hm.. it seems I missed this part of quickstart and I'm not using this pre-build script for schemes. and for android, I'm using not flavors but build types.

yes, your solution sounds good.

[berdyshev]

@maxkomarychev can I already use this interceptor? or is it something that should be developed?

[maxkomarychev]

@berdyshev sorry for not being clear, this functionality does not yet exist. While it's quite simple one I'm not sure if I'll get to it in the coming days. Pull requests are welcome. I can suggest options how to implement it if you're willing to take it.

[berdyshev]

@maxkomarychev what's about not providing such a callback but just implement this logic inside the library so in case there are folders like ios/fastlane and/or android/fastlane copy a .env file there during yarn rnuc .env.dev run?

[maxkomarychev]

There's a bit more to this than just copying env files from rnuc space to fastlane, here are few:

1. YAML: rnuc command can accept YAML files and therefore simply copying files won't work for this kind of set up. In addition YAML files can also have per-platform values defined
2. (opinionated) Unnecessary schemes/flavors: considering what you have mentioned above regarding firebase set up you could really collapse your schemes/flavors into one and use the hook to copy needed files (GoogleService-Info.plist and the JSON alternative for android) into projects from outside making native projects a bit simpler. These files does not necessarily have to be stored as part of native project neither having firebase setup has to be a reason to use multiple schemes/flavors.
3. Potential security risks: making rnuc to be a single source of truth may and will lead to values not really relevant for runtime of the app but relevant for build process to be stored in these files. Without some kind of filtering or scoping such values may be shipped as part of the app distribution to end users.
4. Having general purpose callback will allow consumers of a library to have write own plugins allowing more flexible setup than just autodetecting fastlane. It doesn't mean such plugin can't be part of a library.

I may be overthinking it to some degree though. Let me know what do you think.
Thanks.

[maxkomarychev]

hi @berdyshev , I just published v3.2.0 which has support of hooks that can be used to generate dotenv files for fastlane. hope it helps.

[maxkomarychev]

@berdyshev I am going to close this one. New version of library offers capability to generate env files for fastlane. Feel free to reopen if you have ideas/suggestions.
Thanks for feedback!