GitHub Actions のログは、失敗したときほど長くなります。
全部を上から読むより、失敗ステップとエラー周辺だけを先に整理したほうが、原因にたどり着きやすくなります。

こんな場面で使う

たとえば、PRのCIでテストが落ちたとします。
ログにはインストール、ビルド、テスト、後処理が混ざっていて、どこから読むべきか分かりにくいことがあります。

GitHub Actions Visualizer にログやワークフロー情報を貼り付けると、ジョブやステップ単位で流れを確認しやすくなります。

Run npm test
FAIL tests/api/user.test.ts
Expected status 200, received 401

この場合、まず見るべきなのはテスト全体ではなく、401 を返したテストケースと、その前に設定された環境変数です。

実例：失敗行だけを抜き出す

長いログを共有するときは、全体を貼るよりも、まず失敗の周辺だけを切り出します。

Run npm run test
FAIL tests/api/user.test.ts
  GET /api/users
    Expected status 200, received 401
Error: missing TEST_API_TOKEN

このログなら、見るべき候補はテストコード、APIの認証設定、CIのsecret設定です。npm install の警告や成功したテストケースまで貼ると、レビュー側が原因にたどり着くまで時間がかかります。

Regexテスターで FAIL|Error:|Expected を含む行を抽出し、テキストユーティリティで前後の空行を整えると、IssueやPRコメントに貼りやすい調査メモになります。

原因を絞る順番

最初に失敗したステップを確認します。
次に、エラーの直前に出ているコマンドと環境名を見ます。
最後に、同じワークフロー内の成功ジョブとの差分を確認します。

よくある原因は次のようなものです。

  • 必要な環境変数が設定されていない
  • キャッシュが古い
  • Node.js やパッケージのバージョンが違う
  • テスト用トークンの期限が切れている
  • 特定のOSだけでパスの扱いが違う

ログを短くして共有する

原因調査のあと、チームに共有するログは短くします。
失敗ステップ、エラー本文、直前の設定だけを抜き出すと、レビューする側も状況を追いやすくなります。

必要なら Regex やテキストユーティリティで、長いログから FAIL、ERROR、warning を含む行だけに絞るのも有効です。

再実行する範囲を決める

原因が外部APIや一時的なネットワークではなく、設定漏れやテストデータの問題なら、ただ再実行しても同じ失敗になります。ログ整理の目的は、原因を見つけるだけでなく「再実行で直る失敗か」を判断することでもあります。

retryで直りやすい: registry timeout, temporary network error
retryで直りにくい: missing secret, wrong path, assertion failed

このように分類しておくと、CIを無駄に回す前に、修正すべきファイルや設定へ意識を向けられます。

関連ツール