なぜ必要なのか
社内の休暇アプリで社員が休みを申請します。開発者は残日数ルールの変更を自動チェックと一緒に確認します。別のホストを採用するより、既存のGitLabで議論とCIを保つことが重要です。
どう解決するのか
MRを開くと、設定したCIルールがrunnerで残日数を検査します。失敗したら修正して再実行し、レビュアーがマージを判断します。
休暇残日数の変更を、検査失敗・修正・再実行とともにレビュー社員の休暇アプリ · 設定した検査の例
検査結果と一緒にレビュー
MR休暇残日数のルールを変更
ソースブランチ:leave-balance
.gitlab-ci.yml↓ MRイベントのルール + runner
- 失敗
01 / 残日数の検査
残日数を超える申請を誤って許可
- 修正
02 / ブランチを更新
ルールを直して再実行
- 成功
03 / 新しい検査結果
レビュアーが結果と変更を判断
検査成功 → レビューの根拠 → マージの判断
設定が必要です。このMRパイプラインはソースブランチを検査し、マージ結果を自動検査しません。成功は配布の承認ではありません。
どんな考え方なのか
GitLabはGitホスティング、MR、CIを組み合わせます。設定とrunnerの容量が必要です。MRパイプラインはソースブランチを検査し、マージ結果を自動的に検査するわけではありません。サービス利用と自主運用では責任が異なります。
出典
さらに詳しく
任意の参考資料 · 概要の読了時間には含みません
01選択・比較
リポジトリのレビューと設定済みCIを一緒に扱う価値が大きいときに選びます。他のホストでも検査とレビューを連携できます。GitLab.comはGitLabが運営し、Self-Managedではチームがインスタンスを管理します。必要な機能を満たせば、Giteaによる小規模な自主運用も候補です。
02応用例
休暇アプリの例のテストは残日数を超える申請の拒否を確認します。MRには失敗した実行と修正後の成功が表示されます。合格はレビューの根拠であり、全休暇ルールの証明や自動配布の承認ではありません。
03実装の参考・注意点
.gitlab-ci.ymlにMRイベントのルールを定義し、適切なrunnerを用意します。通常のMRパイプラインはソースブランチを検査するため、必要ならマージ結果の検査も別に確認します。ホスト型の枠と自主運用・更新・復元の費用を比較します。Git履歴に加え、課題、CI設定、アクセス設定の移行も試します。
04根拠
比較のまとめ
続けて読む
原稿・修正提案 ↗自分のプロジェクトに活かす
これからプロジェクトを始めますか?説明を入力して最初のプロンプトを準備しましょう。
自分に合うプロンプトを作る →すでに外部AIと会話中なら、この記事のリンクと自分のプロジェクトに合う理由、重視する利点や制約を伝えましょう。合意した要件にどう適用するか依頼してください。
この記事のリンク: GitLab
この選択を話し合う
コメントは全言語で共有。投稿にはGitHubログインが必要です。