なぜ必要なのか

社内の休暇アプリで社員が休みを申請します。開発者は残日数ルールの変更を自動チェックと一緒に確認します。別のホストを採用するより、既存のGitLabで議論とCIを保つことが重要です。

どう解決するのか

MRを開くと、設定したCIルールがrunnerで残日数を検査します。失敗したら修正して再実行し、レビュアーがマージを判断します。

休暇残日数の変更を、検査失敗・修正・再実行とともにレビュー

社員の休暇アプリ · 設定した検査の例

検査結果と一緒にレビュー

MR

休暇残日数のルールを変更

ソースブランチ:leave-balance

.gitlab-ci.yml↓ MRイベントのルール + runner
  1. 失敗

    01 / 残日数の検査

    残日数を超える申請を誤って許可

  2. 修正

    02 / ブランチを更新

    ルールを直して再実行

  3. 成功

    03 / 新しい検査結果

    レビュアーが結果と変更を判断

検査成功 → レビューの根拠 → マージの判断

設定が必要です。このMRパイプラインはソースブランチを検査し、マージ結果を自動検査しません。成功は配布の承認ではありません。

どんな考え方なのか

GitLabはGitホスティング、MR、CIを組み合わせます。設定とrunnerの容量が必要です。MRパイプラインはソースブランチを検査し、マージ結果を自動的に検査するわけではありません。サービス利用と自主運用では責任が異なります。

出典