React-native-firebase: Duplicating run script phase for Fabric Crashlytics

Created on 9 Nov 2019  路  13Comments  路  Source: invertase/react-native-firebase

Documentation Feedback

Here
https://invertase.io/oss/react-native-firebase/v6/crashlytics/ios-setup

It shouldn't be necessary adding this run script step
"${PODS_ROOT}/Fabric/run"

Because step before is
[CP-User] [RNFB] Crashlytics Configuration
It is automatically added from Crashlytics and include this script

set -e

if [[ ${PODS_ROOT} ]]; then
  echo "info: Exec Fabric Run from Pods"
  ${PODS_ROOT}/Fabric/run
else
  echo "info: Exec Fabric Run from framework"
  ${PROJECT_DIR}/Fabric.framework/run
fi

Is it a duplication right?

Crashlytics Docs Stale >= 6

Most helpful comment

@afladmark as I mentioned in #2146 The Fabric API key not valid error happens because you probably previously installed the Fabric app and then migrated your apps to Firebase.
The Fabric app added keys to your info.plist.
Instead of inserting the Fabric API and _BUILD_SECRET keys to the script each time you install the module, you can just delete the Fabric keys from your info.plist, and the script should work.

All 13 comments

It does indeed appear to be a duplication. I also receive an error:

info: Exec Fabric Run from Pods
2019-11-09 19:06:23.953 uploadDSYM[56877:3336148] Fabric.framework/run 1.8.0 (212)
error: Fabric: Configuration Issue

Fabric API key not valid. Your Fabric run script build phase should contain your API key:
./Fabric.framework/run INSERT_YOUR_API_KEY INSERT_YOUR_BUILD_SECRET

Which I resolved by pasting my API key and build secret into both run lines. I'm not sure if this is the correct way to resolve this (but it does). Would be good to clarify in the documentation as well.

@afladmark I think in practice the correct edit is really to say "generating dSYMs at build time is usually pointless from the perspective of investigating release-mode crashes", c.f. https://stackoverflow.com/a/55796619/9910298

I simply disable that script, and use fastlane to download dsyms from apple post-processing then push them to crashlytics

Hmm. I don't really have a strong view on whether it's useful or not. I previously had the script in my project (presumably by the manual integration I'd done for Crashlytics) and when switching to RNFB it adds the script automatically, but as-is, I'm unable to build without either removing/disabling it or providing the keys. So I think that needs addressing somehow as it doesn't work "out of the box" without some further action.

Perhaps disabled by default with a prompt in the docs of how to provide the keys and enable it if wanted?

Actually, one thing I hadn't considered is that we're also originally Fabric Crashlytics customers so that may be why it's different for us. The current docs for Firebase Crashlytics don't seem to need these keys, but for some reason we do.

Perhaps disregard my issue then, but @claudioviola's original point still stands. The docs tell you to do something that's now done automatically.

yeah - not sure about original Fabric customers migration needs - at this point that's special case but I'm sure you're not unique. Should be documented somewhere? And yes does seem like a docs issue - there's an edit button top-right of every docs page that takes you through an easy editing fork/branch/edit/submit-pull-request flow (all on one page, really) so anyone can propose changes to clean things up - most of the docs edits are from users helping other users, it's one of the best ways to make an impact on the project

@afladmark as I mentioned in #2146 The Fabric API key not valid error happens because you probably previously installed the Fabric app and then migrated your apps to Firebase.
The Fabric app added keys to your info.plist.
Instead of inserting the Fabric API and _BUILD_SECRET keys to the script each time you install the module, you can just delete the Fabric keys from your info.plist, and the script should work.

@yogeverez Thank you very much for that tip! I hadn't seen the other issue. We've finally finished porting all our analytics events over from Fabric Answers so this was the last missing link in our migration. Much appreciated!

Hey @afladmark, @claudioviola, hope you are well!

Also having this issue, is there a workaround in the interim that still uploads dSYM file to firebase?

Fastlane is absolutely marvelous.

@KevinLeigh
Fastlane works very well but there was an issue on Google... I don't remember right now... You should check... but I had implemented this lane

`
platform :ios do
desc "Refresh dSYM to Crashlytics"

private_lane :refresh_dsyms do |options|
    # Load content of dotenv file based on param `env`
    Dotenv.load("../../.env.#{options[:env]}")

    download_dsyms(
        app_identifier: ENV["APP_ID"],
        version: 'latest'
    )

    upload_symbols_to_crashlytics(
        dsym_paths: lane_context[SharedValues::DSYM_PATHS],
        gsp_path:"../env/#{options[:env]}/ios/GoogleService-Info.plist",
    )

    clean_build_artifacts()
end

desc "Upload dSYM to Production Crashlytics"
lane :refresh_dsyms_production do
    refresh_dsyms(env: 'production')
end

end
`

Interesting - in case it helps anyone else to share, here are my dsyms lanes also, I don't use dotenv but I pass an env name as parameter:

  lane :refresh_latest_dsyms  do |options|
    environment = options[:environment] || 'dev'
    environmentUCfirst = environment.capitalize
    puts "Refreshing dSYMs for environment " + environment

    download_dsyms(version: 'latest', username: apple_username, team_id: apple_team_id, app_identifier: bundle_base + (environment == 'prod' ? '' : '.' + environment))
    upload_symbols_to_crashlytics(gsp_path: apple_plist_base + '/' + environmentUCfirst + '/GoogleService-Info.plist', binary_path: apple_dsym_uploader)
    clean_build_artifacts
   end

  lane :refresh_recent_dsyms  do |options|
    environment = options[:environment] || 'dev'
    environmentUCfirst = environment.capitalize
    puts "Refreshing dSYMs for environment " + environment

    download_dsyms(min_version: '2.0.3', username: apple_username, team_id: apple_team_id, app_identifier: bundle_base + (environment == 'prod' ? '' : '.' + environment))
    upload_symbols_to_crashlytics(gsp_path: apple_plist_base + '/' + environmentUCfirst + '/GoogleService-Info.plist', binary_path: apple_dsym_uploader)
    clean_build_artifacts
   end

   lane :refresh_all_dsyms  do |options|
    environment = options[:environment] || 'dev'
    environmentUCfirst = environment.capitalize
    puts "Refreshing dSYMs for environment " + environment

    download_dsyms(username: apple_username, team_id: apple_team_id, app_identifier: bundle_base + (environment == 'prod' ? '' : '.' + environment))
    upload_symbols_to_crashlytics(gsp_path: apple_plist_base + '/' + environmentUCfirst + '/GoogleService-Info.plist', binary_path: apple_dsym_uploader)
    clean_build_artifacts
   end

I'm not using fastlane to do google publishes actually. I have it on my todo list, but I might mention in a separate Android-only project (AnkiDroid) we use the "Triple-T" publisher and it works well. I would never do without fastlane for ios though, it's really magic, especially for certificate management when you have to re-do provisioning profiles etc.

Hello 馃憢, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

Closing this issue after a prolonged period of inactivity. If this is still present in the latest release, please feel free to create a new issue with up-to-date information.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dgruseck picture dgruseck  路  3Comments

jonaseck2 picture jonaseck2  路  3Comments

csumrell picture csumrell  路  3Comments

n-scope picture n-scope  路  3Comments

Draccan picture Draccan  路  3Comments