一日のシミュレーター
昼の便では、Issueを何本か承認してから時計を進めてください。毎時3分から10分おきにai_pickが動き、その時点で承認済みのIssueをまとめて拾います。夜の便を選ぶと、夕方に承認した3本を22時3分に拾う流れになります。
13:00
承認済み0
実装中0
MRを人が読む0
止まった0
マージ済み0
MRの札の「読んでマージ」と、止まった札の「直して流し直す」は、人がする操作です。実装にかかる時間は目安で、昼の便は10月2日の試走(1本1分前後)、夜の便は9月30日の試走(広めのIssueで約20ターン)をもとにしました。Runnerの枠は8本で、あふれた分は順番を待ちます。
ラベルの移り変わり
Issueの状態は、ラベルで受け渡します。人が付けるのはai::approvedだけで、残りはパイプラインが付け替えます。
ラベルなし書いたところ
→人が付ける
ai::approved承認
→ai_pick
ai::running実装中
→MRを出した
ai::doneMRあり
→人がマージ
ClosedIssueが閉じる
↓止まった
ai::stopped理由のコメント
←人が本文を直して外す
- Issueを書いたばかりのときは、状態のラベルがありません。この間、AIは何もしません。
- 人が
ai::approvedを付けると、承認になります。付けるのは人だけで、パイプラインはこのラベルを付けません。 ai_pickが拾うと、ai::runningが付きます。次の起動は、この印のあるIssueを拾いません。- 実装ジョブがMRを出すと、
ai::doneに替わります。Issueには、MRのURLとターン数と費用のコメントが付きます。 - 人がMRを読んでマージすると、Issueは自動で閉じます。
- 曖昧な受け入れ条件、決まっていないこと、外れた承認、25分の打ち切りのどれかに当たると、
ai::stoppedに替わります。理由はコメントに残ります。 - 人が本文を直して
ai::stoppedを外すと、ai::approvedだけが残ります。次の便で、もう一度拾われる仕組みです。 - Community Editionでは、同じ
ai::の印でもラベルが並んで付きます。そのためai::approvedは、最後まで付いたまま残ります。
スケジュールの決まり
| スケジュール | 書いた間隔 | 実際に動く時刻 | 有効にする期間 |
|---|---|---|---|
| AIサイクル(午後の研修) | */10 * * * * | 毎時3分、13分、23分のように10分おき | 10月6日の昼休みの終わりから、夜に回す節の前の休憩まで |
| AIサイクル(夜間) | 0 22 * * * | 22時3分 | 10月5日の夕方から、10月7日の朝まで |
GitLabがスケジュールを見回る仕組みは、10分おきの枠(3-59/10)で動いています。そのため、書いた時刻のあとの最初の枠で起動します。スケジュールは作った人の権限で動くので、mainで実行できるrootで作りました。
昼の便を夜に回す節の前に外すのは、受講者が今夜の分として承認したIssueを、その場で拾わせないためです。外し忘れると、夜の便を待たずに昼の便が拾ってしまいます。
昼の便と夜の便の違い
| 項目 | 昼の便 | 夜の便 |
|---|---|---|
| 起動 | 10分おきのスケジュールと、講師のNew pipeline | 22時3分のスケジュール |
| 承認 | ラベルai::approved | 同じ |
| 上限 | 30ターンと25分 | 同じ |
| push | ジョブのスクリプトだけが行う | 同じ |
| 人がいるか | いる。MRをその場で読む | いない。翌朝にまとめて読む |
| 止まったとき | その場で本文を直し、次の便で流し直す | 翌朝に直し、昼の便か次の夜に載せる |
夜の実装ジョブは、確認を求める設定(ask)を置いても、朝まで待ち続けるだけです。そのため夜のClaudeにはpushの権限を渡さず、許可の外の操作は確認なしで拒否します。