FirebaseCrashlyticsへのupload-symbols実行時にCould not fetch upload-symbolsのエラーが発生する

リリースしたアプリのクラッシュログ分析などでよく用いられるFirebaseCrashlytics。
FirebaseCrashlyticsを使用して、クラッシュログをもれなく収集するには、ライブラリ内のメソッドを使用するなどしてdsymファイルをFirebaseにアップロードする必要があるのですが、ここで表題の`Could not fetch upload-symbols`のエラーが発生しました。同じエラーが発生した人の助けになればと思います。

## 結論

結論から記述すると、Firebase側のコンソール設定が完了していなかったことが原因でした。
ただ、権限の関係で本番環境のコンソールが確認できなかった、なぜかFabricのライブラリ内にあるコマンドではアップロードができてしまった、などの複数の要因から原因に気づくのにも時間がかかりました。
コンソール画面の閲覧権限がないなど、同じような事象に出くわす方もいるかと考え、今回の記事作成に至りました。

## どんなことをしたか

### FirebaseCrashlyticsについて

まずFirebaseCrashlyticsについて簡単に説明しておきます。
Firebaseが提供しているサービス。ライブラリの導入とアプリ起動時に数行の設定コードを記述することで、クラッシュログを収集しコンソール画面で管理ができます。

[公式ドキュメント](https://firebase.google.com/docs/crashlytics/get-started)に従ってセットアップする必要があります。
（日本語記事もありますが、記述が古い箇所があるので英語ドキュメントを参照するのがよいと思います）
本記事はこのセットアップ過程の中でFirebaseCrashlyticsのdSYMファイルアップロードの工程についての記事となります。

CrashlyticsはもともとFabricによって提供されていたサービスで、FabricのFirebaseへの統合に伴い、CrashlyticsもFirebaseに移行されました。もともとFabricを使っていた場合、dSYMアップロードの際に若干方法が異なるので注意が必要です。

### dSYMのアップロード方法

[FirebaseCrashlyticsの公式ドキュメント](https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports)に書いてある方法ですが、以下のコマンドをターミナルなどのコマンドラインから叩くことでアップロードが可能です。

```
/path/to/pods/directory/FirebaseCrashlytics/upload-symbols -gsp /path/to/GoogleService-Info.plist -p ios /path/to/dSYMs
```
GoogleService-Info.plist・dSYMファイルのパスを指定して、ライブラリに用意されているコマンドを叩きます。
アップロードに成功すると`Successfully uploaded Crashlytics symbols`が表示されます。

Fabricを使っている場合には、この叩くべきコマンドが以下に変わります。

```
/path/to/pods/directory/Fabric/upload-symbols -a <FabricAPIKey> -p ios /path/to/dSYMs
```

Fabricの場合は、FabricのAPIKeyを指定してあげないといけないみたいです。

### 発生したエラーとその原因

FirebaseCrashlyticsライブラリのコマンドにて実行した際に、以下のエラーが発生しました。

```
Fetching upload-symbols settings...
error: Could not fetch upload-symbols settings: An unknown error occurred fetching settings.
```

調べてみると**協業先のアカウントではFirebaseCrashlyticsの設定が行われていなかった**ことがわかりました。
これを設定後に再度試してみると、無事`Successfully uploaded Crashlytics symbols`となり、アプリリリース後も無事クラッシュログを収集できました。

本来、アカウント側の設定は一番最初に実施すべき工程として公式ドキュメントに記載されているので、完全なる凡ミスではあるのですが、開発用と本番用とでアカウントをわけていたり、コンソールが確認できないなどの事情があると、こう言ったケースは起こりうるのではないかなと思います。
当該のエラーが出た方がいたら、まずはアカウント側の設定を見直していただければよいかもしれません。

## 補足
冒頭で「なぜかFabricのライブラリ内にあるコマンドではアップロードができてしまった」というふうに書きました。
これはアップロードに失敗した時に、試しにFabricで用意された下記のコマンドを叩いてみるとなぜかSuccessしてしまう、という事象でした。

```
/path/to/pods/directory/Fabric/upload-symbols -gsp /path/to/GoogleService-Info.plist -p ios /path/to/dSYMs
```

その後Firebase側のコンソール設定が未完了ということが判明したのですが、なぜこのFabricのコマンドではSuccessしてしまうのかが謎のままでした。

しかしこの記事を書く過程でみつけた[記事](https://tomolog.reafo.io/jp/article/firebase-de-dysm-upload-suruhouhou)でこんな記述にあたりました。

> Fabric時代のアプリも通常のコマンドでアップロードして「Successfully uploaded Crashlytics symbols」と表示されるのですが、Firebase上では追記したコマンドでやらないといつまでたっても認識されていないようでした。

この記事の通常のコマンドとは、gspオプションでGoogleService-Info.plistのパス指定しているコマンドを指しているのですが、こちらの指定方法だとSuccessと表示されるものの、Firebase側には反映されていないようです。
もしかするとこちらのコマンドを叩いていることで、見かけ上成功しているが実際はアップロードされていなかったのかもしれません。
Fabricの場合のコマンドをググると、2パターンの指定方法がひっかかってしまいますが、APIキーを指定するコマンドを使わなくてはならないようですので、その点も要注意です。

## 参考
[Firebase公式 - Get deobfuscated crash reports with the Firebase Crashlytics SDK](https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports)
[Tomo.Log() - FirebaseでdSYMをアップロードする方法が変わってた](https://tomolog.reafo.io/jp/article/firebase-de-dysm-upload-suruhouhou)