自動化処理

自動化処理は、誰かが指示しなくても常に作業を開始します。それはスケジュールに従って実行されるか、何らかの事象が発生したときに動作します：pull requestが開かれたり、課題が登録されたり、チェックやデプロイが失敗したりします。

すべての自動化処理は、工場内の『自動化処理』セクションに一覧表示され、それを起動するきっかけと実行内容が記載されています。『新規作業』から作成できます：『自動化』を選択し、実行タイミングを指定してください。

2種類のトリガー#

トリガーが時間に関連する場合や、監視対象がSentryやJiraなどCoroidイベントを送信しない他システムにある場合はスケジュールを利用します。スケジュールはそのシステムに問い合わせます。MCPサーバーそして見つかった内容に基づいて作業を開始します。詳細はスケジュール。

Coroidが事象発生を即座に通知できる場合はイベントを利用します。これにより、繰り返し問い合わせるスケジュールよりも無駄な作業が減ります。

『新規作業』で選択可能なイベント#

GitHubからのもので、これが必要ですGitHubアプリ：

• pull requestが開かれたり、更新されたり、マージされたりします。
• 課題が開かれます。
• コメントでCoroidが言及されます。ただし、リポジトリへの書き込み権限を持つユーザーのコメントのみが対象となります。

Coroidから：

• 課題、計画、品質管理、デプロイ、またはデプロイヘルスチェックが失敗します。
• リリースがロールバックされます。

SlackやTelegramのメッセージ、新しいJira課題、独自システムが発行するイベントにはフィルターやサービスアカウントが必要です。『設定』内の『自動化処理』にあるテンプレートから開始するか、エディタで自動化処理のイベントを変更してください。詳細はフック。

実行内容#

イベントが発火すると、自動化処理は3つのうち1つを実行します：

• pull requestをレビューします。Coroid Checkがそれをレビューし、GitHub上にレビュー結果を投稿します。該当行にコメントが付き、チェック実行名はCoroidレビューとなります。これは開かれたり更新されたりしたプルリクエストに対して提供されます。
• それを作業に変換します。イベントはリクエストとして登録されます。資格審査を通過すると、Coroidが課題や計画を作成します。これは課題やCoroidが言及されたコメントに対して提供されます。
• 指示に従います。エージェントがあなたが記述した指示に従い、読み取り専用のアクセス権で課題を開くことができます。これはすべてのイベントに対して提供されます。

いずれの場合もコードを直接変更することはありません。自動化処理が開始した作業は、他のものと同じ仕様、計画、ビルド、検証、レビューのプロセスを経て、最終的にあなたが承認するpull requestとなります。

すべてのpull requestをレビューする#

Coroidが自身のものだけでなく、ユーザーが開いたプルリクエストもレビューさせるには：

1. 『新規作業』を開き、『自動化処理』を選択します。
2. プロジェクトを選択するか、空欄のままにしてすべてのプロジェクトを対象にします。
3. 『トリガー』で『何かが発生したとき』を選択し、『イベント』で『プルリクエストが開かれたとき』を選んで、『pull requestをレビュー』を指定します。
4. タイトルと簡単な指示を入力して続行してください。

この自動化処理は、該当プロジェクトの新しいpull requestおよびその更新内容をすべてレビューします。リポジトリにはGitHubアプリが必要で、プロジェクトが『ローカルのみ』に設定されていてはなりません。Coroid自身の課題からのプルリクエストは再レビューされません：そのレビューは課題の一部だからです。

また、『品質管理』でプロジェクトのプルリクエストを有効にすることもできます。そうすると、そのプロジェクトのチェックがすべてのpull request上でも実行され、Coroid Checkが同じ実行プロセスの一部としてレビューを行います。

自動化処理の監視#

工場内で自動化処理を開くと、各実行の実施時刻、コスト、作成された作業、実行が完了しなかった理由を確認できます。そこから所有者や管理者が一時停止、テスト、編集、削除を行えます。組織内の全員が自動化処理とその実行履歴を閲覧できます。

自動化処理を有用なままに保つ#

自動化処理が開始した作業は、他のものと同じエージェントスロットを争います。頻繁に実行される自動化処理は、気付かないうちにリソースを使い果たしてしまう可能性があります。

1. 人が依頼した作業よりも低い優先度を設定してください。 P2またはP3。
2. トリガーを具体的に設定します。「チェックが失敗した」というトリガーは繁忙なリポジトリでは頻繁に発火します。「このチェックがベースブランチで失敗した」というトリガーは実際に問題がある場合にのみ発火します。
3. 生成された結果を確認します。自動化処理が20件の課題を作成して、そのうち2件しかマージされなかった場合、それは価値ではなくノイズとコストを生み出していることになります。

自動化処理の真の評価基準は、発火頻度ではなく、作成された作業のうちマージされた割合です。

Sentinel#

以前のバージョンのドキュメントでは、条件を監視するモニターであるSentinelについて説明していました。これは別個の機能ではありません。条件とは、自動化処理が実行できるイベントか、スケジュールがチェックする内容のいずれかです。

関連項目#

• スケジュール
• フック
• 作業を開始する方法
• ソフトウェア製造プラットフォーム