Origin に runner は無いので、PR Check だけ Depot CI に載せた

Cursor の Origin にリポジトリを置いた瞬間、GitHub Actions で回していた PR Check が止まって見える。Origin 側に runner が無いからだ。Apps から Depot を繋ぎ、.depot/workflows/ を default branch に置くと、Origin の PR 上で check が走る。

Windows の PR Check は載せた。OS 非依存の Core（restore / build / test / 脆弱性監査）は Linux の Depot で回る。残したのは、Windows マシンが要る WASAPI / WPF / self-contained publish と、macOS の xcodebuild、release。Depot に Windows / macOS のサンドボックスが無い。

対象は日英リアルタイム字幕アプリ RealtimeTranslator。macOS は Swift、Windows は .NET で、shared/ の fixture と文言を両実装の契約にしている。

Origin の CI は GitHub Actions ではない

手元の git remote はこう分かれている。

• cursor … Origin（origin.cursor.com）。PR とマージの本番
• origin … GitHub のミラー

Depot を繋ぐ先も Origin 本体だけ。Depot の画面には同じ名前のリポジトリが二つ出る。六角形が Origin、Octocat が GitHub ミラー。下の kinopeee-interpreter-openai に繋いでも webhook は来ない。

オンボーディングの分岐も紛らわしい。改善対象で CI workflows を選んだあと、実行方法を聞かれる。

上の Migrate to Depot CI が .depot/workflows/ を読む経路。下の Swap in Depot GitHub Actions runners は、GitHub Actions の runs-on を差し替える話なので、Origin では動かない。Origin に GitHub Actions の runner が無い。

CLI は brew install depot/tap/depot で入れた。当時の版は 2.102.7。depot login のあと、namespace は Origin の kinopee、リポジトリは kinopee/interpreter-openai だけ繋いだ。

接続そのものはすぐ終わる。画面は次に 3 ステップを出すが、全部やらなくてよい。

1. Install the Depot CLI … 済み
2. depot ci migrate workflows … 実行しない。こちらで .depot/workflows/ を既に置いてある。回すと既存の GitHub Actions がコピーされるので、macos.yml / windows.yml / release.yml まで入る
3. depot ci migrate secrets-and-vars … 不要。Depot に載せた 2 本は secrets を使っていない。署名用の secrets は release.yml 側に残したまま

下の Waiting for the first webhook は、GitHub ミラーへ push しても消えない。画面にも Note がある。Depot が見るのは Origin-native だけ。確認するには cursor remote へ commit を push するか、Origin 上で PR を開く。

何を移して、何を残したか

Origin の PR ゲートに載せたのはこの 2 本。どちらも depot-ubuntu-24.04 で回る。

• shared-contracts … shared/fixtures/v1 と shared/locales/ui.json の契約 Check
• windows-core … Windows 実装の Core。638 tests と脆弱性監査。Linux でも同じ結果になる部分だけ

windows.yml 全体を Depot にコピーしたわけではない。solution には Core のほか、WASAPI の Platform、WPF の App、Platform.Tests が入っていて、self-contained publish も win-x64 前提だ。ここは GitHub Actions の windows-latest に、solution ごと残した。同じ理由で macos.yml と release.yml も残している。

動かないジョブを必須 check に足すより、薄い YAML を自分で置いたほうが早い。

Check の正本は YAML ではなくシェルにした

Depot と GitHub Actions で同じ Check を二箇所に書くと、すぐズレる。正本はスクリプトにした。

• scripts/ci-shared-contracts.sh
• scripts/ci-windows-core.sh

ローカルでも同じコマンドが走る。

./scripts/ci-shared-contracts.sh
./scripts/ci-windows-core.sh

手元では fixture 9 件が schema と対になり、locale は 142 keys。Core は 638 tests、脆弱性パッケージなし。GitHub 側の shared-contracts も同じスクリプトを呼ぶ。Windows の Origin 側ゲートは Depot の windows-core が担う。GitHub の windows.yml は、今も solution 全体を windows-latest で build / test / publish する。

Windows Core 側で一つはまった。windows/global.json は SDK 10.0.100（rollForward: latestFeature）を要求するのに、PATH 先頭の dotnet が古い系統だと見つからない。スクリプトは DOTNET_ROOT、~/.dotnet、/usr/local/share/dotnet から満たす SDK を選ぶ。CI 用というより、手元の PATH が汚れているときの保険。

脆弱性監査も dotnet list ... --vulnerable の終了コードを信じない。このコマンドは脆弱性を見つけても 0 を返すことがあるので、JSON を読んで advisory があれば失敗させている。判定のやり方は GitHub 側の windows.yml と同じ。見る対象は Core のテストプロジェクトだけだ。

Depot の workflow は薄い

.depot/workflows/shared-contracts.yml はこれだけ。

name: shared-contracts

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  validate-fixtures:
    name: validate shared fixtures
    runs-on: depot-ubuntu-24.04
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false

      - uses: actions/setup-node@v7
        with:
          node-version: '24'

      - name: Validate shared contracts
        run: ./scripts/ci-shared-contracts.sh

windows-core も同じ形で、actions/setup-dotnet@v6 のあと ./scripts/ci-windows-core.sh を呼ぶ。runs-on は depot-ubuntu-24.04。global-json-file は windows/global.json。

発火用に ci/depot-origin-pr-checks から PR #8 を開いた。Depot 上の実測は validate shared fixtures が 12 秒、build and test (windows core) が 33 秒。ゲートとしてはこれで足りた。

必須 check の残骸がマージを止めた

workflow が通っても、branch protection 側に古い必須 check が残るとマージできない。検証用に足していた Local CI Reporter が Protect default branch に残っていた。

Depot の 2 本は 12 秒と 33 秒で終わっている。止まっているのは Local CI だけ。状態は Not started。CLI の API キーでは ruleset を消せなかったので、Settings の Rules and Protections から外した。

画面の Changes が +5010 に見えるのは、当時の Origin main が GitHub より遅れていて、CI 以外の履歴も PR に乗ったため。CI 本体のコミットは 6 ファイル、+241 / -59 である。

Bugbot の指摘は check 失敗ではない

必須を差し替えたあと、PR #8 は Ready to merge になった。Bugbot は Found 1 issue と出している。

必須にしているのは Cursor Bugbot の status check の完了だ。「Found 1 issue」はレビューコメントで、check 自体は成功することが多い。指摘があるのにマージできるのは、この切り分けのせい。

指摘でマージを止めたいなら、承認必須を足すか、Bugbot 側で finding を check failure にする必要がある。今の「Depot が通ればマージ」なら、指摘は別 PR で直せばいい。#8 の指摘は #9 で直した。#9 に対する次の指摘は #10 で直した。

承認必須は一人運用だと詰まる

試しに Require approving reviews を 1 にした。Auto-merge はオンなのに、次の PR で止まった。

Bugbot の No issues found はレビューコメントで、Approve には数えない。Require review from code owners も一緒にオンにしていたが、このリポジトリに CODEOWNERS は無い。所有者不在のまま必須にすると、承認待ちが解消しない。

一人で回しているなら、承認はオフでよい。必須は status check だけにした。

オフに戻すとヘッダーに Merge が出る。Approve ボタンは消える。任意の Review の中には残るが、マージ条件ではない。

今の分担

Origin の PR ゲートは Depot の shared-contracts と windows-core、それに Bugbot。Windows の Core テストはここで見る。

GitHub Actions に残しているのは、windows.yml の solution 全体（Core も含む）と win-x64 publish、macos-26 の xcodebuild、Developer ID 署名と公証。Depot に Windows / macOS サンドボックスが来るまで、この二系統でとりあえず様子見。