複数言語の大きなデータ基盤モノレポを直し、プルリクエストを用意する

## 最初の編集の前に、Gitのリモートを確かめて正しいブランチを選ぶ セッションで最初の編集またはテストを行う前に、次を実施する。 1. 個人のforkと正本のupstreamリモートを特定する。役割が不明なら、標準のリモート構成を設定するよう依頼する。 2. upstreamのデフォルトブランチのタイムスタンプを確認し、ローカル参照が古い場合は更新する。 3. ワーキングツリーを調べ、コンテキストを切り替える前に未コミットの変更を保護するようユーザーへ依頼する。 4. タスクに応じてブランチを選ぶ。 既存のレビューでは、そのheadブランチを特定し、一致するローカルブランチがあれば使用して切り替えを報告する。一致するものがなければ、取得するか、別名のローカルブランチを使うか確認する。新しい編集では、upstreamのデフォルトブランチを起点にした分離worktreeを推奨案として提示するか、そのブランチを起点に新しいブランチを作る。テストだけを行う場合は、upstreamのデフォルトブランチを使用する。 ## ゴールデンテストの出力とプロトコルのファイルは、手で直さず作り直す ゴールデンテストの出力は、それを生成するテストハーネスに属する。実行または更新の前にスイートの文書を読み、生成済みの期待値ファイルを直接編集してはならず、サポート対象のワークフローで再生成する。受け入れる前に、生成された差分を慎重に確認する。 プロトコル定義は、そのスキーマソースに属する。メッセージやフィールドを変更する前に、定義とともに保存されている文書を読み、生成済みのプロトコル成果物を手作業の編集対象に含めない。 ## CIの前に、コードをASCIIと1行の文字数の上限に収める 文字列リテラルまたはテストフィクスチャの内容でASCII以外の文字が本当に必要な場合を除き、識別子、コード、コメントはASCIIに保つ。コメントへ気付かないうちに入りやすい組版用ダッシュ、スマート引用符、省略記号、ノーブレークスペースが変更ファイルにないか、抜き取り確認する。 ソース行は、一般に100文字とされるリポジトリの上限内に収める。追加または変更したソースファイルの簡易スキャンでは、import、package宣言、URLの除外を概算できるが、あくまで参考にすぎない。言語別のリンターを最終的な判定基準とする。 ## テストに足りる、いちばん小さいJVMのテストベースを選ぶ 必要な動作を提供する最小のテストベースを選ぶ。通常のランタイムテストやユーティリティテストでは、共通のタイムアウト、一時ファイル、ロギング、エラーヘルパーだけを備えたコアスイートを使用する。論理プラン、アナライザー、オプティマイザー、プランナーのテストでは、SQLセッションを起動しないプランテスト用ベースを使用する。 SQLまたはテーブルのテストでは、クエリテスト用ベースを使用し、明示的なセッションプロバイダーをmixinする。通常のSQLテストではインプロセスセッションを選び、ウェアハウスの動作が必要な場合に限ってウェアハウス対応プロバイダーを選ぶ。近くのテストが使っているという理由だけで、より広範なフィクスチャのコストを負担してはならない。 ## Pythonのテストベースを、ローカル・リモート・混合で使い分ける 通常のPythonテストでは、標準のユニットテストベースを使用する。コンテキストレベルのテストでは、分離性を得るためにテストごとに新しい実行コンテキストを作成するか、速度を優先してクラスごとに1つを再利用できる。SQLとDataFrameのテストでは共有classicセッションベースを使用し、DataFrame拡張のテストでは列指向実行と専用アサーションを追加してもよい。 リモートプロトコルのテストでは、別途判断が必要になる。サーバーが不要ならプラン専用のmockフィクスチャ、実際のリモート動作には再利用するリモートセッション、同等性の確認にはclassicとremoteを組み合わせたフィクスチャを使用する。SQLユーティリティ、構造化エラーのアサーション、等価性ヘルパーは、必要なランタイムを生成する場合を除き、テストベースではなくmixinまたは独立したヘルパーとして扱う。 ## 変えたモジュールだけをビルド・テストし、全部のテストの前に聞く ビルドとテストには高いコストがかかる場合がある。ユーザーがテストを明示的に依頼した場合は実行する。それ以外では、時間のかかるフルスイート検証を始める前に、追加の編集を予定しているか確認する。リポジトリの高速なインクリメンタルビルドツールを優先し、影響を受けるモジュールとそのテストコードだけをコンパイルして、反復中は単一のスイートまたは名前を指定したケースを実行する。 モジュールテストの反復時間を短縮できる場合は、インクリメンタルビルドのシェルを開いたままにする。ビルド済みバックエンドに依存するPythonスイートでは、最初に必要な機能プロファイルをビルドし、ユーザーが選んだ仮想環境または文書化されたデフォルト環境を有効にする。その環境が存在しない場合に限って作成する。プロジェクトのテストランナーが提供するスイートセレクターとケースセレクターを使用する。 ## 1つを直す前に、失敗したCIのチェックを全部洗い出す どれか1つの失敗を調べる前に、レビュー対象コミットで失敗したすべてのチェックを列挙する。テスト概要チェックが成功している、または存在しないからといって、CIがすべて成功しているとは限らない。リンター、ライセンス、依存関係、互換性チェック、コンパイル、文書ビルドは、テスト注釈のない別ジョブで失敗する場合がある。 テストジョブでは、失敗注釈を使ってスイート、ケース、メッセージを取得する。テスト以外のジョブでは、失敗したステップを特定し、そのジョブに絞ったログを読む。構造化された注釈に有用な証拠がすでに含まれている場合は、非常に大きなシャード化テストログのダウンロードを避ける。 ## クローズと表示されたプルリクエストが、本当はマージ済みかを確かめる クローズと表示されたレビューが却下されたと決めつけてはならない。カスタムツールでマージするプロジェクトもあるため、正常にマージされたレビューでも、ホスティングサービス上では標準のマージ時刻がないクローズ状態として表示される場合がある。 プロジェクトのマージ状態ヘルパーを使い、変更が取り込まれたか、どのプライマリブランチまたはメンテナンスブランチに含まれているかを判定する。オープン、マージ済み、マージなしでクローズを別々の結果として扱い、認証情報の不足、浅い履歴、未知のレビュー、upstreamリモートの欠如は、環境上の制約として報告する。 ## プルリクエストのタイトルと説明を、プロジェクトの決まりどおりに書く 文書化されたドラフト、作業中、軽微、自明な変更の例外も含め、issue識別子とコンポーネントタグに関するプロジェクトのタイトル規約に従う。差分からタイトルを推定する。必須のissueがない場合は、正確なコンポーネントと、issue種別または参照先の親を指定してプロジェクトヘルパーから作成し、作成したissueとフィールドをレビュー用に目立つ形で表示する。 説明文を起草する前にリポジトリのプルリクエストテンプレートを読み、すべてのセクションを埋める。issueトラッカーが省略形のタイトルタグではなく完全なコンポーネント名を要求する場合は、完全な名前を使用する。 ## pushは自分のforkだけにし、外へ書き込む前に許可を取る 正本のupstreamリポジトリには決してpushせず、コントリビューターのforkだけへpushする。ユーザーが明示的に依頼しない限り、すでにリモートにあるコミットをforce-pushしたりamendしたりしてはならない。リモートブランチが先に進んでいる場合は、pushする前にfetchしてrebaseする。 コミットのpush、プルリクエストやissueの作成、コメントの投稿など、外部への書き込みを行う前に明示的な承認を得る。プロジェクトがサポートする認証済みクライアントを使用する。利用できない場合は、必須のワークフローを迂回せず、レビュー用URLまたは正確な引き継ぎ手順を用意する。 ## 変更が最初にリリースされるブランチのバージョン番号を使う コードにバージョン注釈、設定バージョン、互換性の除外指定が必要な場合は、その変更が最初にリリースされるブランチのバージョンを使用し、snapshot接尾辞を外す。メンテナンスブランチを基点とするレビューでは、そのブランチのバージョンを使用する。 プライマリブランチを基点とするレビューで、変更を通常そこへbackportする場合は、最新リリースブランチのバージョンを使用する。破壊的変更やバイナリ非互換の変更、または重要なbackportに値しない依存関係のアップグレードなど、プライマリブランチだけに適用する作業に限って、プライマリブランチのバージョンを使用する。リリース経路が不明な場合は、プライマリブランチだけから推測せず確認する。 ## セキュリティの問題を報告する前に、セキュリティポリシーを読む セキュリティ問題を報告する前に、リポジトリのセキュリティポリシーと脅威モデルを読む。スキャナーの結果をプロジェクトが実際に保証する範囲に照らして評価できるよう、明示された対象範囲、除外事項、脆弱性と見なさないことが文書化された事例を確認する。 セキュリティ調査を通常のバグ切り分けと分け、証拠を保持し、発見事項を文書化する際に認証情報や機密性の高いローカルデータを露出させない。