@logbrew/sdk 0.1.28 の Vite プラグインを使います。Vite のアプリ、そのビルド出力へのアクセス、プロジェクトのキーを作成する権限が必要です。Apple のデバッグファイルについては、Apple のクラッシュとハングを参照してください。
ビルドとイベントをそろえる
アップロードとアプリの実行時のイベントには、同じプロジェクト、リリース、環境、サービスを使います。バージョン名については、リリースを参照してください。このガイドでは、web@1.2.3、staging、checkout-web を使います。
ビルドされたコードが変わったら、リリースを変えます。準備したビルドをアップロードしてから、そのビルドをそのままデプロイします。アップロード後に再ビルドしたり、JavaScript を変更したりしないでください。
Vite プラグインを追加する
アプリのディレクトリに SDK をインストールします。vite.config.js にプラグインを追加します。他のプラグインやビルドの設定はそのまま残します。プロジェクト ID を置き換えます。
minifiedPathPrefix は、ビルドのディレクトリをデプロイした先の URL です。プラグインは、そのディレクトリ内の各ファイルのパスを付け加えます。たとえば、dist/assets/app.js は https://app.example.com/assets/app.js になります。ビルドを /web で配信している場合は、プレフィックスに /web を含めます。プレフィックスに /assets は追加しないでください。
upload オプションがない場合、プラグインは LogBrew に何も送信しません。また、次のことも行います。
build.sourcemapを設定していない場合は、"hidden"に設定します。falseに設定している場合は、"hidden"に変更してください。- 圧縮ツールのオプションを設定していない場合は、関数名を保持します。独自に設定している場合は、その設定で名前を保持してください。
ビルドしてローカルで確認する
本番用のビルドを実行します。sourcesContent と、ローカルのアプリのルートパスを削除します。そして dist/logbrew-release-artifacts.json を書き出します。
マニフェストを開きます。validation.status が ready であること、このビルドのファイルとデプロイ先の URL が含まれていることを確認します。hidden のマップでは、sourceMappingURL comment missing の警告が出ます。この警告は想定どおりです。
非公開のパスや、共有したくないソースのテキストを含むマップはアップロードしないでください。アップロードにはコンパイル済みの JavaScript も含まれるため、シークレットはアプリのバンドルに入れないでください。
アップロードをローカルで確認します。このコマンドはリクエストを送信せず、キーも不要です。
0 で終了し、"status": "dry_run" を出力した場合にだけ先に進みます。これはローカルのファイルとマニフェストを確認するもので、サーバーはテストしません。ビルドで別の出力ディレクトリを使っている場合は、両方のパスを変更します。
対応付けを確認するには、ビルドしたアプリを実行し、生成されたスタックフレームを1つ、ファイル、行、列と一緒にコピーします。
"status": "resolved" があることを確認します。original オブジェクトに、ソースのファイル、行、列が示されます。このコマンドはローカルで実行され、何もアップロードしません。
ビルド成果物キーを作成する
LogBrew CLI でサインインします。プロジェクト ID を確認します。--abandon-retry は使わないでください。
ビルド成果物キーはプロジェクト単位で、書き込み専用です。ソースマップとデバッグファイルをアップロードします。テレメトリの送信や、ビルド成果物のメタデータの読み取りはできません。代わりにアカウントの認証情報や、実行時の SDK キーを使わないでください。
キーは、ビルド環境のシークレット設定に LOGBREW_RELEASE_ARTIFACT_TOKEN として保存します。表示したりコミットしたりしないでください。VITE_* や EXPO_PUBLIC_* など、クライアントから見える変数に入れないでください。
この変数は、アップロードを実行するプロセスで設定します。ヘルパーは .env ファイルを読みません。Vite も、設定の評価の間はそれらのファイルを process.env に読み込みません。
準備したビルドをアップロードする
確認済みの同じファイルとマニフェストを使います。このコマンドは、LogBrew にアップロードを送信します。"status": "uploaded" は、LogBrew がアップロードを受け付けたことを示します。コマンドがエラーで終了した場合は、作業を止め、下の表を使ってください。
ヘルパーは、ネットワークエラー、408、429、5xx のレスポンスに対して、最大2回再試行します。毎回、同じ準備済みのファイルを送信します。回数を変えるには --max-retries を使います。
手動のアップロードが成功したら、代わりに Vite のビルド中にアップロードすることもできます。プラグインの設定に次のオプションを追加します。
dryRun: true を追加します。
プラグインは、出力ディレクトリからソースマップを削除しません。.map ファイルやマニフェストを、公開の Web サイトや CDN にデプロイしないでください。
取得した課題のフレームを対応付けるには、そのフレームを指定して、同じ準備済みのビルドに対して symbolicate-js を実行します。
新しい課題を読む
同じ準備済みのビルドをテスト環境にデプロイします。課題を取得する経路で、安全なテスト用のエラーを1つ発生させます。このテストでは、ユーザーの入力、認証情報、生のスタックを送信しないでください。 同じプロジェクトとビルドのコンテキストで、新しい課題を探します。event.stack_frames を読みます。source: "symbolicated" のフレームには、アップロードしたファイルから得た元のファイル、行、列があります。source: "captured" のフレームには、アプリが送信した位置があります。
logbrew read issue "<issue_id>" --json も symbolication オブジェクトを返します。その中の各フレームには status があり、値は resolved、artifact_not_found、source_not_resolved、invalid_metadata、unavailable のいずれかです。元の位置があるのは、resolved のフレームだけです。
LogBrew は、課題を読み取るときにフレームを対応付けます。エラーの後にアップロードしても、同じ Debug ID を持つ以前のイベントを対応付けられます。対応付けたフレームは、調べるべきコードを指します。エラーの原因を示すものではありません。他のフィールドについては、課題を調査するを参照してください。
確認に失敗したときの対処
サポートへのメッセージに、ソースファイル、キー、非公開のパスを含めないでください。トラブルシューティングと API エラーを参照してください。