168 lines
7.4 KiB
Markdown
168 lines
7.4 KiB
Markdown
# Dependabot PR レビュー
|
||
|
||
DependabotによるPRを依存関係更新の観点から包括的にレビューしてください。
|
||
|
||
## 実行手順
|
||
|
||
1. **PR情報の取得**
|
||
- `gh pr view $ARGUMENTS` を実行して、PRの基本情報を取得
|
||
- `gh pr diff $ARGUMENTS` を実行して、変更内容の差分を取得
|
||
- PRの作成者がdependabotであることを確認
|
||
|
||
2. **依存関係の更新内容を分析**
|
||
以下の観点で詳細に分析してください：
|
||
|
||
### 更新内容の確認
|
||
- 更新される依存関係の名前
|
||
- 現在のバージョンから更新後のバージョン
|
||
- セマンティックバージョニング上の変更種別を判定:
|
||
- メジャーバージョンアップ（例: 1.x.x → 2.x.x）: Breaking changesの可能性が高い
|
||
- マイナーバージョンアップ（例: 1.2.x → 1.3.x）: 新機能追加、後方互換性あり
|
||
- パッチバージョンアップ（例: 1.2.3 → 1.2.4）: バグ修正、後方互換性あり
|
||
|
||
### リリースノートとCHANGELOGの確認
|
||
- 可能であれば、更新される依存関係のリリースノートやCHANGELOGを確認
|
||
- GitHub上でのリリースページを参照（gh CLIやWebSearchを活用）
|
||
- 主な変更内容を要約
|
||
|
||
### Breaking Changesの調査
|
||
- メジャーバージョンアップの場合、Breaking changesの詳細を調査
|
||
- 非推奨APIの削除や変更がないか
|
||
- 影響を受ける可能性のある箇所を特定
|
||
- マイグレーションガイドの有無
|
||
|
||
### セキュリティ脆弱性の確認
|
||
- セキュリティアップデートかどうかを判定
|
||
- CVE番号や脆弱性の詳細があれば記載
|
||
- 深刻度レベル（Critical, High, Medium, Low）
|
||
- 影響範囲と緊急度
|
||
|
||
### 互換性の評価
|
||
- プロジェクトの他の依存関係との互換性
|
||
- Node.js、Python、Rubyなどのランタイムバージョン要件
|
||
- peer dependenciesとの整合性
|
||
- 既存コードへの影響範囲を推定
|
||
|
||
### テスト結果の確認
|
||
- GitHub Actionsやその他のCIステータスを確認
|
||
- `gh pr checks {PR番号}` を実行してテスト結果を取得
|
||
- 失敗しているテストがあれば原因を調査
|
||
|
||
### プロジェクトコードへの影響調査
|
||
更新される依存関係がプロジェクト内でどのように使用されているかを詳細に調査してください：
|
||
|
||
1. **依存関係の使用箇所を特定**
|
||
- Grep ツールを使用して、更新されるパッケージのimport/requireステートメントを検索
|
||
- パッケージ名やモジュール名で検索（例: `import ... from 'package-name'`, `require('package-name')`）
|
||
- 検索結果から使用しているファイルと行番号をリスト化
|
||
|
||
2. **APIの使用状況を調査**
|
||
- Breaking changesで変更・削除されるAPIがプロジェクト内で使用されているか確認
|
||
- 非推奨となったメソッドやプロパティの使用箇所を検索
|
||
- 具体的なファイルパスと行番号を特定（例: `src/utils/helper.ts:42`）
|
||
|
||
3. **影響範囲の評価**
|
||
- 直接的な使用箇所の数を集計
|
||
- 影響を受けるファイルの重要度を評価（コアロジック、ユーティリティ、テストコードなど）
|
||
- 変更が必要なコード量を見積もり
|
||
|
||
4. **依存している機能の確認**
|
||
- プロジェクトが使用している具体的な機能やメソッドを特定
|
||
- それらの機能が更新後も同様に動作するか評価
|
||
- 代替方法が必要な場合はマイグレーションパスを提示
|
||
|
||
5. **間接的な影響の調査**
|
||
- 更新される依存関係に依存している他のコードを特定
|
||
- 型定義の変更による影響（TypeScriptの場合）
|
||
- グローバルな設定やプラグイン設定への影響
|
||
|
||
3. **レビュー結果の出力**
|
||
以下の形式で結果を出力してください：
|
||
|
||
```markdown
|
||
# Dependabot PR #{PR番号} レビュー結果
|
||
|
||
## 📦 更新内容
|
||
- パッケージ名: [package name]
|
||
- 現在のバージョン: [current version]
|
||
- 更新後のバージョン: [new version]
|
||
- 変更種別: [Major/Minor/Patch]
|
||
|
||
## 📋 リリースノート要約
|
||
[主な変更点を箇条書きで記載]
|
||
|
||
## 🔒 セキュリティ情報
|
||
- セキュリティアップデート: [Yes/No]
|
||
- CVE番号: [CVE-XXXX-XXXXX または N/A]
|
||
- 深刻度: [Critical/High/Medium/Low または N/A]
|
||
- 脆弱性の詳細: [説明]
|
||
|
||
## ⚠️ Breaking Changes
|
||
[Breaking changesがある場合は詳細を記載、なければ「なし」]
|
||
|
||
## 🔍 互換性チェック
|
||
- ランタイム要件: [問題なし / 要確認]
|
||
- 他の依存関係との整合性: [問題なし / 要確認]
|
||
- 既存コードへの影響: [なし / 軽微 / 中程度 / 大]
|
||
|
||
## ✅ テスト結果
|
||
- CIステータス: [Pass/Fail/Pending]
|
||
- 失敗しているテスト: [あれば記載]
|
||
|
||
## 🔎 プロジェクトコードへの影響
|
||
|
||
### 使用箇所
|
||
[依存関係が使用されているファイルと行番号をリスト化]
|
||
- `path/to/file1.ts:15` - [使用方法の簡単な説明]
|
||
- `path/to/file2.js:42` - [使用方法の簡単な説明]
|
||
|
||
**合計使用箇所**: [N個のファイル]
|
||
|
||
### Breaking Changesの影響
|
||
[変更が必要な箇所を具体的に記載]
|
||
- ✅ 影響なし
|
||
- または
|
||
- ⚠️ `path/to/file.ts:line` - [具体的な変更内容]
|
||
|
||
### 必要な対応
|
||
[コード修正が必要な場合、具体的な対応方法を記載]
|
||
- [対応が不要な場合は「なし」]
|
||
- [対応が必要な場合は、ファイルごとに必要な変更内容を記載]
|
||
|
||
### 影響度
|
||
- 直接的な影響: [高/中/低]
|
||
- 変更の複雑さ: [高/中/低]
|
||
- 推定作業時間: [見積もり]
|
||
|
||
## 📝 推奨アクション
|
||
|
||
### 🟢 即座にマージ可能（以下のいずれか）
|
||
- パッチバージョンアップで、テストが全て通過
|
||
- セキュリティ修正で、Breaking changesなし
|
||
- マイナーバージョンアップで、互換性問題なし
|
||
|
||
### 🟡 注意してマージ（以下の確認後）
|
||
- [確認すべき事項をリスト化]
|
||
|
||
### 🔴 マージ前に対応が必要
|
||
- [必要な対応をリスト化]
|
||
|
||
## 💡 その他の推奨事項
|
||
- [追加の提案があれば記載]
|
||
|
||
## 📊 総合評価
|
||
**マージ推奨度**: [⭐⭐⭐⭐⭐ (5段階)]
|
||
|
||
[総合的な判断理由を記述]
|
||
```
|
||
|
||
## 注意事項
|
||
- Dependabotのコミットメッセージには有用な情報が含まれているため必ず確認すること
|
||
- セキュリティアップデートは優先的にマージを検討すること
|
||
- メジャーバージョンアップの場合は慎重に評価すること
|
||
- テストが失敗している場合は原因を特定すること
|
||
- 複数の依存関係が同時に更新される場合は、それぞれについて評価すること
|
||
- プロジェクトコードへの影響調査は必須で実施すること。Grepツールを活用してimport/requireステートメントを検索すること
|
||
- Breaking changesがある場合は、影響を受けるコードの具体的な修正方法を提示すること
|
||
- 使用箇所が多い場合や影響が大きい場合は、段階的な移行計画を提案すること
|