ブログに戻る
X24LABS

Stitch Agent (v1) のはじめ方

オリジナルの v1 セットアップガイド: 2つの CI ジョブ、Docker イメージ、そして少数の環境変数。歴史的な参考のため残しています。

歴史的な記事です。 このガイドは Stitch v1 について説明しています。v1 は CI パイプラインの中で動き、Docker イメージで配布されていました。今日 Stitch をインストールするなら、代わりに Getting started with Stitch 2.0 に従ってください。stitch-monitor / stitch-heal ジョブと ghcr.io/x24labs/stitch イメージはもうメンテナンスされていません。

Stitch のセットアップは5分もかかりません。CI 設定に2つのジョブを追加すれば、あとは Stitch が処理します。サーバーも、管理すべき API キーも、監視するダッシュボードもありません。

前提条件

GitLab CI のセットアップ

これらの2つのジョブを .gitlab-ci.yml に追加します:

stitch-monitor:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch monitor
  when: on_failure

stitch-heal:
  stage: .post
  image: ghcr.io/x24labs/stitch:latest
  script:
    - stitch heal
  needs: ["stitch-monitor"]
  when: on_failure

stitch-monitor ジョブは上流のジョブが失敗したときに起動します。ログを読み、失敗を特定します。stitch-heal ジョブは診断を受け取り、修正を生成します。

両方のジョブは .post ステージを使うため、通常のパイプラインステージがすべて終わった後に動きます。トリガーは on_failure のみなので、パイプラインが通れば計算時間のコストはゼロです。

GitHub Actions のセットアップ

ワークフローファイルを .github/workflows/stitch.yml に追加します:

name: Stitch
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  heal:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/x24labs/stitch:latest
    steps:
      - uses: actions/checkout@v4
      - run: stitch monitor && stitch heal

このワークフローは CI ワークフローが失敗したときにトリガーされます。コードをチェックアウトし、monitor を実行し、修正を適用します。

その後に起きること

パイプラインが失敗すると:

  1. Stitch が失敗ログを読みます
  2. エラーの種類と影響を受けたファイルを特定します
  3. 的を絞ったパッチを生成します
  4. 失敗したチェックを再実行して修正を検証します
  5. 修正が通れば、fix ブランチに commit を push して merge request を開きます

MR は他のコード変更と同じようにレビューします。デフォルトでは auto-merge は無効です。修正をいつ着地させるかはあなたが決めます。

設定

Stitch は設定なしで動きます。より細かく制御したいチームは、環境変数でオプションを設定できます:

セットアップの検証

わざと lint ルールかテストを壊す commit を push します。パイプラインが失敗し、Stitch が拾う様子を見てください。数分以内に新しいブランチと merge request が現れるはずです。

うまく動かない場合は、Stitch ジョブのログを確認してください。そこには完全な診断と、修正試行中に発生したエラーが含まれています。

次のステップ

ブログに戻る