GitHub Actionsを使用して変更を検証する

トランクベースの開発が実施されると、提案されたすべての変更がプル要求を通過します。 そのプル要求は、自動チェックを実行する自然な瞬間でもあります。 トレーニング スクリプトを中断する変更は mainに達するべきではありません。レビュー担当者は、すべてのコード エラーを手動でキャッチする必要はありません。

ワークフロー、トリガー、品質ゲート

GitHub Actions ワークフローは、.github/workflows/のリポジトリに格納されている YAML ファイルです。 実行する内容、実行するタイミング、および順序を定義します。 トリガー (on: キー) は、GitHubを開始するタイミングを通知します。

Proseware 検証ワークフローの場合、 pull_request トリガーはタスクに適合します。 既定では、プル要求が開いたり、再度開いたり、新しいコミットを受け取ったりするときに実行されます。 その結果は、プル要求の 状態チェック として表示されます。

ジョブ、ランナー、ステップ

ワークフローは、作業をジョブに整理 します。 各ジョブはランナー (GitHubまたは組織が管理する仮想マシン) で実行されます。 ジョブには、リポジトリのチェックアウト、ツールのインストール、コマンドの実行を行う順序付けされた 手順 が含まれています。

Proseware トレーニング コードの場合、検証ジョブは次の場合があります。

1. リポジトリを確認します。
2. リンター (Python用のフレーク 8 など) をインストールし、トレーニング スクリプトに対して実行します。
3. 単体テスト (Pytest など) を実行して、スクリプト関数が正しく動作することを確認します。

これらの手順は、すべてのプル要求で自動的に実行されます。 誰もそれらをローカルで実行する必要はありません。

チェックを行う必要があります

チェックを自動的に実行することは、保護の半分にすぎません。 もう半分は、それらのチェックをブロッキングにすることです。 ブランチ保護の設定では、[ マージ前に状態チェックを渡す必要があります ] オプションを使用すると、特定のジョブに名前を付けられます。 指定されたジョブが成功するまで、プル リクエストはマージできません。

トランクベースの開発と必要な状態チェックを組み合わせることで、品質ゲートが形成されます。データ サイエンティストがプル要求を開き、ワークフローが実行され、コードが渡されるまでマージ ボタンは無効なままです。