Hi,
We use Bitrise to upload DSYM for crashlytics tool during our deployment process.
We have all the steps set to always use the latest version.
Over the last month we have noticed that the DSYMs are uploaded to Crashlytics by the Bitrise step and Crashlytics doesn’t complain about any missing DSYMs.
But when we do actually have a crash, it comes out as hidden.
I tried manually building and uploading the DSYMs and that shows the crash debug info correctly.
Also, when we upload the DSYMs we get the following message in the build logs:
Successfully submitted symbols for architecture arm64 ...
warning: skipping Apple dSYM: ...
Do you have the crash in an AppStore / TestFlight build?
From the Crashlytics docs:
There can be certain situations however, when dSYM uploads fail because of unique project configurations or if you’re using Bitcode in your app.
In short, if you use bitcode Apple re-compiles the app on their servers, which means the original dSYM won’t work anymore. You need the dSYMs from the App Store / iTunes Connect directly.
We distribute the app via Fabric Beta and yes, we are using Bitcode in our app.
I investigated it further and it seems the issue is with the Bitrise build upload route.
I can’t figure out what has changed in those steps which could be causing this issue as our workflow hasn’t been changed. Please advise and I have also shared the project for “Bitrise support” if you need access.
I added the script step but it failed when I used the pods command.
I then changed the “Pods” to “Fabric.framework” as we are not using Cocoapods and it still failed with:
"/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/bitrise697172187/step_src/._script_cont: line 8: ./Fabric.framework/upload-symbols: No such file or directory"
The existing step “fabric-crashlytics-beta-deploy” is using the following path:
Submitting DSYM...
/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/bitrise697172187/step_src/Fabric/upload-symbols -a "03313f28417cd1cd3595b819fd900244f0279465" -p ios "/Users/vagrant/deploy/NinjaAppEnterprise.dSYM.zip"
This uploads the DSYMs with the following warning:
2018-01-18 07:15:32.550 upload-symbols[9506:35342] Successfully submitted symbols for architecture arm64 with UUID 72f3b285570033cbb1d8f0ae5dd6751b in dSYM: /var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T///Users/vagrant/deploy/NinjaAppEnterprise.dSYM.zip.unzipped/__dsyms__121541944/72F3B285-5700-33CB-B1D8-F0AE5DD6751B.dSYM
warning: skipping Apple dSYM: /var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T///Users/vagrant/deploy/NinjaAppEnterprise.dSYM.zip.unzipped/__dsyms__121541944/032500CD-693D-3842-8CF7-4857DACE9C5C.dSYM
w
Is this warning expected?
Also, is the fabric-crashlytics-beta-deploy step using upload-symbols script from the framework I checked in or is it using its own version of the script?
If it’s the later, is it possible that the fabric-crashlytics-beta-deploy step is outdated?
That’s exactly what I suspect to be the case here.
Can you please check the content of the framework (right click → show content, or similar) on your Mac and see where the upload-symbols is, and try to run the script with that again?
I spent some time looking for upload-symbols script inside the checked in frameworks. Apparently, its not part of the iOS frameworks instead they have another script called uploadDSYMs.
It’s part of the MacOS app. I extracted it out and checked it in with my project and added a script step with the following command:
./FabricMacApp/upload-symbols -a "$FABRIC_API_KEY" -p ios "$BITRISE_DSYM_PATH"
The step did run and uploaded the DSYMs but, Fabric is still unable to decode the crash.
If I run the same upload-sumbols script locally on my machine then Fabric is able to decode the crash.
This means that the DSYMs being generated via the Bitrise route are not right and hence we see the
warning: skipping Apple dSYM:
during DSYMs upload.
I checked the project settings and the highest selectable stack in Bitrise is
Xcode 9.2.x (including betas), installed on macOS 10.12 (Sierra).
All of our machines in our office are on macOS 10.13.2 (High Sierra) running Xcode 9.2 (9C40b).
Could this be causing the incorrect DSYM generation on Bitrise?
When I run the script on my Mac, I don’t see the warning lines.
I checked the upload-symbols command and they are exactly the same i.e. no further debug argument being sent.
I was checking all the workflow steps and this one:
Quite unlikely, as that Step (the Xcode Archive one) does not perform any transformation / modification, neither on the code nor on the ipa; all it does is it runs Xcode (xcodebuild) with the params appropriate for its input (Scheme, project file, etc.).
You say there’s no warning if you run the upload from your Mac - that’s a good lead!
Could you please download the dSYM from bitrise.io, from the build’s page, and try to upload that from your Mac? Just to see what happens with the exact same dSYM.
Thanks for the explanation.
I downloaded the Bitrise generated DSYMs and uploaded them via the local script and I do see the same warning.
warning: skipping Apple dSYM: /var/folders/s6/8fb6jx9s6vd7jblm4sd8dhsm0000gp/T//Archive.zip.unzipped/C59C6DE1-A843-30F6-9FDD-21DBA994A038.dSYM
2018-01-19 14:38:44.455 upload-symbols[11935:396348] Successfully submitted symbols for architecture arm64 with UUID 2aabb75482c63ca1bcab03fa1b22a499 in dSYM: /var/folders/s6/8fb6jx9s6vd7jblm4sd8dhsm0000gp/T//Archive.zip.unzipped/NinjaTracking.framework.dSYM
When Xcode generates DSYMs on my machine, I end up with one DSYM per library.
The one generated by Bitrise step seems to be way more than that. And the additional ones seemed to be named with a UUID.
Do I need to change some setting to clean up the DSYM folder?
Sorry, for the delay in response.
When running Bitrise CLI locally what is the correct way to make the code signing files available?
I tried downloading the *.mobileprovision and the *.p12 files and placing them in the same directory as the bitrise.yml but, still ran into the following error:
