depot-ci

Depot CI

Depot CI は、エンジニアとエージェント向けのプログラム可能な CI システムです。Depot CI のワークフローはすべて Depot のコンピューティング環境で実行され、ジョブの可視性、デバッグのしやすさ、制御機能が組み込まれています。Depot CI が最初にサポートする構文は GitHub Actions です。既存の GitHub Actions ワークフローを移行すれば、最適化されたインフラストラクチャで高速かつ信頼性の高い実行を実現できます。

この SKILL.md では、基本的なワークフローとよく使うコマンドを説明します。詳細なフラグ一覧、JSON 出力の形式、使用頻度の低いコマンドについては、関連するセクションから参照できる references/ 内の各ファイルに記載されています。必要な情報が含まれる場合にのみ、該当するリファレンスファイルを読み込んでください。

アーキテクチャ

3 つのサブシステムで構成されています。コンピューティング（作業環境をプロビジョニングして実行）、オーケストレーター（複数ステップのワークフローをスケジュールし、依存関係を処理）、GitHub Actions パーサー（Actions の YAML をオーケストレーターのワークフローに変換）です。システム全体をプログラムで制御できます。

共通フラグ

ほぼすべての depot ci コマンド（および depot tests）で、次のフラグを使用できます。

• --org <id>：組織 ID です。ユーザーが複数の組織に所属している場合は必須です（以下の「複数組織ユーザーの組織コンテキストの確認」を参照）。
• --token <token>：Depot API トークンです。
• -o, --output json：機械可読形式の出力です。エージェントやスクリプトで便利です。ほとんどの depot ci サブコマンドでは -o の短縮形を使用できますが、depot tests、depot ci secrets、depot ci vars では長い形式の --output のみ使用できます。

リファレンスファイルのコマンド別一覧では、記載を簡潔にするためにこれらのフラグを省略していますが、使用可能であると考えてください。

複数組織ユーザーの組織コンテキストの確認

ユーザーが複数の組織に所属している場合は、セットアップや移行の前に、または CI コマンドで想定するワークフローが見つからない場合に、まず Depot の組織コンテキストを確認してください。

depot org show              # Current org ID
depot org list              # Orgs the user belongs to
depot org switch <org-id>   # Option A: switch default org for this shell/session

# Option B: keep current org and target explicitly per command
depot ci run --org <org-id> --workflow .depot/workflows/ci.yml

ワークフローやリポジトリが現在のデフォルトとは別の組織にある場合は、--org <org-id> を使用してください。

はじめに

1. Depot Code Access GitHub App をインストールする

Depot ダッシュボード → Settings → GitHub Code Access → Connect to GitHub。（Depot で Claude Code を使用したことがある場合は、すでにインストールされている可能性があります。）

2. ワークフローを移行する

depot ci migrate

この対話型ウィザードでは、次の処理を行います。

1. Depot Code Access アプリがインストールされ、設定されていることを確認します。
2. .github/workflows/ 内のすべてのワークフローを検出し、それぞれの Depot CI との互換性を分析します。
3. 選択したワークフローを、インライン修正とコメントを加えて .depot/workflows/ にコピーし、ローカルアクションを .github/actions/ から .depot/actions/ にコピーします。
4. ワークフローで参照されているシークレットと変数を検出し、インポートの次の手順を表示します。

.github/ ディレクトリは変更されないため、ワークフローは GitHub と Depot の両方で同時に実行されます。**警告：**デプロイやアーティファクトの更新など、副作用を引き起こすワークフローは 2 回実行されます。

3. シークレットと変数をインポートする

depot ci migrate secrets-and-vars

これにより、一時ブランチに GitHub Actions ワークフローを 1 回限りで作成して実行します。このワークフローは、既存のシークレットと変数を読み取り、Depot CI にインポートします。depot ci secrets add／depot ci vars add を使って手動で追加することもできます（以下の「シークレットと変数の管理」を参照）。

移行の詳細（preflight／workflows／secrets-and-vars サブコマンド、それぞれのフラグ一覧、変換される内容の詳細、手動セットアップ）については、references/migration.md を参照してください。

シークレットと変数の管理

シークレット（${{ secrets.NAME }} として参照し、暗号化され、作成後は値を読み取れません）と変数（${{ vars.NAME }} として参照し、値を読み取れます）は、共通のバリアントモデルを使用します。1つの名前に1つ以上のバリアントをグループ化します。各バリアントには値と、ジョブをリポジトリ、GitHub 環境、ブランチ、ワークフローファイルで照合するオプションのセレクター（--repo、--env、--branch、--workflow）が含まれます。セレクターのないバリアントは、組織内のすべてのジョブに適用されます。CLI から4種類すべてのセレクターを直接管理できるため、バリアントの管理にダッシュボードは不要になりました。

シークレットの値は、対話型プロンプト、パイプで渡す stdin、または KEY=VALUE 形式の一括ペアから設定できます（シークレットには --value フラグはありません）。変数の値は、--value、プロンプト、または KEY=VALUE ペアを使用して設定できます。

# Secrets: add (prompt or piped stdin), list, remove
depot ci secrets add SECRET_NAME                                   # Prompts securely
printf '%s' "$NPM_TOKEN" | depot ci secrets add SECRET_NAME        # From stdin (scripts)
depot ci secrets add SECRET_NAME --repo owner/repo --branch main   # Scoped variant
depot ci secrets list
depot ci secrets remove SECRET_NAME

# Variables: add, list, remove
depot ci vars add VAR_NAME --value "some-value"
depot ci vars add VAR_NAME --value "prod" --repo owner/repo --env production   # Scoped variant
depot ci vars list
depot ci vars remove VAR_NAME

すべてのコマンドの詳細（set、bulk、get の各シークレットサブコマンド、すべてのフラグ表、実行時に Depot がどのバリアントを優先するかの判定方法）については、references/secrets-and-variables.md をお読みください。

認証情報の安全な取り扱い

認証情報は機密入力として扱い、出力に表示しないでください。

• 非対話型のフローでは、コマンドラインに直接記述するのではなく、シークレットの値を stdin 経由でパイプしてください（例：printf '%s' "$NPM_TOKEN" | depot ci secrets set SECRET_NAME --from-stdin）。
• シークレットの値をコマンド引数として渡すより、対話型プロンプトを優先してください。コマンド、スクリプト、ワークフロー YAML、ログ、例にシークレットやトークンをハードコードしないでください。
• 外部 CI システムでは、実行時に CI のシークレットストアから Depot の認証情報を渡してください。Depot CI は DEPOT_TOKEN を予約し、信頼されたジョブでのビルドにジョブトークンを注入します。DEPOT_TOKEN という名前の Depot CI シークレットは作成しないでください。
• 明示的に要求されない限り、強制実行や非対話型の破壊的なフラグは避けてください。認証情報に影響するコマンドを実行する前に、対象範囲（組織、リポジトリ、ワークフロー）と意図した対象を確認してください。

ワークフローの実行

# Run a workflow (auto-detects repo from git remotes, applies local uncommitted changes)
depot ci run --workflow .depot/workflows/ci.yml

# Run in a specific org (for multi-org users)
depot ci run --org <org-id> --workflow .depot/workflows/ci.yml

# Run specific jobs only
depot ci run --workflow .depot/workflows/ci.yml --job build --job test

# Trigger a run and stream its logs live
depot ci run --workflow .depot/workflows/ci.yml --job test --follow

# Run a job and connect via SSH
depot ci run --workflow .depot/workflows/ci.yml --job build --ssh

# Debug with a tmate session after step N (requires a single --job)
depot ci run --workflow .depot/workflows/ci.yml --job build --ssh-after-step 3

# Override the auto-detected repository (multiple remotes or no origin)
depot ci run --workflow .depot/workflows/ci.yml --repo owner/repo

# Select Depot Code explicitly for a mirrored repository
depot ci run --workflow .depot/workflows/ci.yml --forge depot

CLI は Git リモートから GitHub、Origin、Depot Code を検出します。Depot Code が自動で選択されるのは、サポート対象のリモートがすべて Depot Code を使用している場合のみです。ミラーされたチェックアウトでは、デフォルトで GitHub または Origin が選択されます。--forge に github、origin、depot を指定すると、フォージを選択できます。リポジトリを選択するには --repo <name> を使用します。一致するリモートがない場合、それらのフォージでは --forge origin または --forge depot を指定してください。

ローカルパッチには、ブランチのリモート状態に対して未プッシュの変更が含まれます。ローカルのみのブランチでは、デフォルトブランチに対する変更が含まれます。CLI はパッチを Depot Cache にアップロードし、actions/checkout の後にアプリケーションのステップを挿入します。再利用可能なワークフローを呼び出すジョブには、パッチを挿入するステップがないため、ローカル変更を含まないマージベースのコードで実行されます。CLI はその旨を警告します。

新しい実行を開始するときにデバッグセッションを開始するには、--ssh／--ssh-after-step を使用します。どちらも --job を正確に1つ指定する必要があり、同時には使用できません。すでに実行中のジョブに接続するには depot ci ssh を使用します。トリガーした実行のログをストリーミングするには --follow を指定します。これは指定された1つのジョブを追跡します。複数のジョブが実行中の場合は、唯一のジョブを選択し、複数ある場合は選択を求めます。--follow は --ssh／--ssh-after-step と同時には使用できません。

ワークフローのディスパッチ

depot ci dispatch は、ターミナルから workflow_dispatch を使ってワークフローを起動します。入力は、ワークフローで宣言された入力スキーマに照らして検証されます（必須入力は指定する必要があり、型付き入力は型に合わせて変換されます）。

depot ci dispatch --repo depot/cli --workflow deploy.yml --ref main
depot ci dispatch --repo depot/cli --workflow deploy.yml --ref main \
  --input environment=staging --input dry_run=true
depot ci dispatch --repo depot/cli --workflow deploy.yml --ref main --output json

--workflow には、ワークフローファイルのベース名（例：deploy.yml）を指定します。GitHub の workflow_dispatch API の規約と同様に、.depot/workflows/deploy.yml のようなフルパスは指定しません。必須フラグは --repo <owner/repo>、--workflow <filename>、--ref <branch-or-tag> です。--input <key>=<value> は複数回指定できます。

depot.actor コンテキストは実行を作成した人を示し、depot.triggering_actor は再試行や再実行を含め、現在の試行を開始した人を示します。どちらも kind、id、email、name を公開します。アクターの種類は user、organization_token、service、github です。メールアドレスを持つのはユーザーのみです。対応する環境変数は DEPOT_ACTOR_KIND、DEPOT_ACTOR_ID、DEPOT_ACTOR_EMAIL、DEPOT_ACTOR_NAME、DEPOT_TRIGGERING_ACTOR_KIND、DEPOT_TRIGGERING_ACTOR_ID、DEPOT_TRIGGERING_ACTOR_EMAIL、DEPOT_TRIGGERING_ACTOR_NAME です。GitHub のアクターコンテキストは、引き続き GitHub と同じ意味を持ちます。

カスタムイメージ

カスタムイメージを一度ビルドし、ジョブ間で再利用すると、セットアップ手順の繰り返しを省略できます。カスタムイメージは Depot CI サンドボックスのスナップショットで、組織の Depot レジストリに保存されます。任意のワークフロー内の任意のジョブから、名前を指定して参照できます。

イメージをビルドする

セットアップ手順を実行するジョブに snapshot: キーワードを追加します。手順の完了後、Depot はサンドボックスの状態を取得し、再利用可能なイメージとして Depot レジストリにプッシュします。スナップショットジョブは、まず指定されたタグがすでに存在するか確認します。存在する場合はジョブをスキップしてスナップショットを再利用し、存在しない場合はジョブを実行してスナップショットを作成します。

jobs:
  build-image:
    runs-on: depot-ubuntu-latest
    snapshot: ci-base:v1
    steps:
      - run: sudo apt-get update && sudo apt-get install -y your-tool

高度な設定を行うには、展開形式の snapshot: を使用します。with: ブロックで基盤となる depot/snapshot-action を設定できます。たとえば、max-age を指定すると、設定した経過時間に達した後に再ビルドされます。

jobs:
  build-image:
    runs-on: depot-ubuntu-latest
    snapshot:
      image-name: ci-base
      version: v1
      with:
        max-age: 5d
    steps:
      - run: sudo apt-get update && sudo apt-get install -y your-tool

バージョンを指定しない場合、Depot は latest タグを使用します。v1 のように明示的なバージョンを指定すると、スナップショットには v1 と latest の両方のタグが付与されるため、利用側は特定のバージョンに固定することも、latest を追従することもできます。

イメージを使用する

runs-on のオブジェクト構文を使い、size と image（どちらも必須）を指定すれば、任意の Depot CI ジョブでイメージを参照できます。

jobs:
  test:
    runs-on:
      size: 2x8
      image: ci-base
    steps:
      - uses: actions/checkout@v4

image の値には、ci-base のような短縮名（Depot が {orgId}.registry.depot.dev/depot/snapshots/ci-base に展開します）または {orgId}.registry.depot.dev/some-image のような Depot Registry の完全な参照を指定できます。スナップショットジョブで作成されたイメージを参照する必要があり、任意のイメージは指定できません。

使用可能なサイズ：2x8、4x16、8x32、16x64、32x128、64x256（CPU 数 x RAM（GB））。

制約： イメージは Depot レジストリ（registry.depot.dev）にプッシュし、同レジストリからプルする必要があります。外部レジストリはサポートされていません。

並列ステップ

Depot CI は、parallel: ブロックを使用して単一のジョブ内でステップを並行実行できます。これにより、ジョブの所要時間をすべてのステップの合計ではなく、最も時間のかかるブランチの所要時間まで短縮できます。これは Depot CI 固有の機能であり、GitHub Actions ランナーとは互換性がありません。

steps: 内で parallel: を使用し、個々のステップまたは sequential: グループを指定します。各ブランチは同じジョブ状態から開始します。ブロックの完了時に、すべてのブランチのステップ出力、環境変数、$GITHUB_PATH の変更が統合されます。

# Run lint, typecheck, and tests concurrently
steps:
  - uses: actions/checkout@v4
  - name: Install dependencies
    run: pnpm install
  - parallel:
      - name: Lint
        run: pnpm lint
      - name: Typecheck
        run: pnpm type-check
      - name: Test
        run: pnpm test

parallel: 内で sequential: を使用すると、1 つのブランチ内で順番に実行する必要があるステップをグループ化できます。

- parallel:
    - sequential:
        - name: Build
          run: npm run build
        - name: Test
          run: npm test
    - name: Lint
      run: npm run lint

fail-fast: で失敗時の動作を制御します。デフォルトは true（ブロック内の残りのステップをキャンセル）です。false にすると、すべてのステップが完了するまで実行されます。

- fail-fast: false
  parallel:
    - name: Lint
      run: pnpm lint
    - name: Typecheck
      run: pnpm type-check

parallel: ブロック内の個々のステップに continue-on-error: true を設定すると、そのステップの失敗が吸収され、グループ全体が成功できるようになります。これは fail-fast: とは異なります。fail-fast: は、失敗発生時に残りのステップをキャンセルするかどうかだけを制御し、グループが失敗するかどうかは制御しません。

- parallel:
    - name: Optional check
      continue-on-error: true
      run: pnpm optional-check
    - name: Required check
      run: pnpm required-check

制限事項：

• parallel: を別の parallel: の中に入れ子にすることはできません（代わりに、parallel: 内で sequential: を使用してください）。
• ステップの id 値は、異なる並列ブロック間も含め、ジョブ全体で一意である必要があります。

ステップの再試行

retry: キーを追加すると、失敗した run: ステップを自動的に再実行し、不安定なコマンド（ネットワークの一時的な切断、レジストリの一時的なエラーなど）から復旧できます。Depot はバックオフ時間の経過後にその場でステップを再実行し、後続の試行が成功すればジョブを続行します。再試行はゼロ以外の終了コードすべてで実行され（終了コードによる絞り込みはありません）、run: ステップのみをサポートします。uses: アクションステップの retry: は、アクションが再実行すると安全でない post: や状態管理の仕組みを持つため、解析時に拒否されます。

省略形式では、追加の試行回数を設定します。

steps:
  - run: npm ci
    retry: 3   # up to 4 total runs

構造化形式では、バックオフと遅延を制御します。

steps:
  - run: ./flaky-integration-test.sh
    retry:
      retries: 3            # additional attempts after the first run (1-10)
      backoff: exponential  # 'constant' (default) or 'exponential'
      delay-seconds: 5      # base delay before the first retry (default 5)
      max-delay-seconds: 60 # cap on a single delay (default 60)

retries: N は、合計で最大 N + 1 回実行することを意味します。constant は各再試行の前に delay-seconds 待機します。exponential は試行ごとに待機時間を 2 倍にし（試行 n では delay-seconds × 2^(n-1) 待機）、max-delay-seconds を上限とします。timeout-minutes は各試行に適用され（試行ごとに新しい制限時間が設定されます）、continue-on-error はすべての再試行を使い切った後にのみ適用されます。再試行では同じサンドボックスを再利用するため、試行間で状態はリセットされません。ステップをクリーンな状態で実行する必要がある場合は、独自のクリーンアップ処理を先頭に追加してください。

サンドボックスの機能

• ネストされた仮想化：すべての Depot CI サンドボックスでは、ハードウェア仮想化がデフォルトで有効になった /dev/kvm が公開されるため、KVM/QEMU、Android エミュレーター、VM ベースのエンドツーエンドテストを追加設定なしで実行できます。
• DEPOT_JOB_URL：各ジョブの環境には、Depot ダッシュボード上のジョブへの直接リンクである DEPOT_JOB_URL が含まれます。
• GitHub チェック：Depot CI は、ワークフロー実行内の各ジョブについて、GitHub チェックを自動的に報告します。

GitHub API の制限によりチェックの更新が遅れる場合、組織のオーナーは Settings → Connections → GitHub Checks で Depot Checks と Depot Checks 2 を接続できます。Depot Code Access はあらかじめ接続しておく必要があります。チェックアプリに同じリポジトリへのアクセス権を付与してください。承認済みの接続が保留中のままの場合は、Finish connecting を使用してください。

チェックアプリを追加する前に、同じ名前のチェックを複数のアプリが公開できるため、必須の Depot チェックソースを Any source に設定してください。Any source にすると、ほかのリポジトリ書き込み権限を持つユーザーも、その名前のチェックを満たせるようになります。アプリ固有の信頼性が必要な場合は、ソースを固定したままにして、追加のアプリをスキップしてください。既存のチェックは元のアプリに紐付いたままであり、そのアプリのレート制限の影響を受ける場合があります。

クラウド認証のための OIDC

Depot CI は各ジョブに署名済み JWT を発行するため、ワークフローでは静的な認証情報ではなく、有効期間の短いトークンを使ってクラウドプロバイダー（AWS、GCP、Azure）に認証できます。トークンを発行するには、ワークフローで permissions: id-token: write を設定してください。発行者は https://identity.depot.dev です。Depot はトークンリクエスト用の認証情報を環境に注入するため、aws-actions/configure-aws-credentials などの標準アクションは追加設定なしで動作します。

プロバイダーの信頼ポリシーの設定、sub の SPIFFE クレーム形式とワイルドカード、トークンの完全なクレーム一覧、および既存の GitHub Actions OIDC 信頼ポリシーの移行については、references/oidc.md を参照してください。

Datadog CI Visibility

Depot 組織の設定で Datadog CI Visibility を有効にしてから、DD_API_KEY という名前の Depot CI シークレットを追加してください。Datadog アカウントで datadoghq.com 以外のリージョンを使用している場合は、DD_SITE も追加してください。Depot は各ワークフローの実行を、そのジョブとステップを含むパイプラインとして Datadog に直接送信します。レポート送信はベストエフォートで行われるため、Datadog 側で障害が発生しても CI の実行は失敗しません。

実行の確認、監視、デバッグ

よく使われるトリアージおよび確認用コマンド：

# Find recent/failed runs (defaults to queued + running)
depot ci run list
depot ci run list --status failed -n 10
depot ci run list --repo depot/api --status failed --pr 42

# Inspect a run's full workflow -> job -> attempt hierarchy
depot ci status <run-id>

# Wait for completion; exit 1 if the run fails or is cancelled
depot ci status <run-id> --wait --output json

# Pull logs (accepts run, job, or attempt ID; auto-selects the job if only one)
depot ci logs <run-id>
depot ci logs <run-id> --job build
depot ci logs <job-id> --follow

# Group and explain a run's failures, with a suggested fix per group
depot ci diagnose --run <run-id>

# Inspect parsed test results (Depot CI or GitHub Actions)
depot tests <attempt-id> --ci --status failed

コマンドの全一覧は references/runs-and-debugging.md にあります。

コマンド	用途
depot ci run list	実行を一覧表示します（トリアージの入口）。ステータス、リポジトリ、sha、トリガー、PR で絞り込めます
depot ci run show	1 件の実行のフラットなレコードを表示します
depot ci workflow list	ジョブごとの件数を含むワークフローの実行を一覧表示します。--name で絞り込めます
depot ci workflow show	1 つのワークフローの実行、ジョブ、試行を表示します
depot ci status	実行 → ワークフロー → ジョブ → 試行の階層全体を表示します
depot ci logs	ジョブログを取得するか、--follow で追跡します。JSON／JSONL 形式でエクスポートできます
depot ci summary	試行の GitHub Actions ステップサマリーを Markdown 形式で表示します
depot ci metrics	試行、ジョブ、または実行の CPU とメモリの使用率を表示します
depot ci artifacts	実行のアーティファクトを list で一覧表示し、ID を指定して download します
depot ci diagnose	グループ化された失敗内容と修正方法を提示し、失敗した実行／ワークフロー／ジョブ／試行を診断します
depot tests	解析済みのテスト結果を一覧表示します。--ci または --gha を指定でき、ステータス／スイート／テストで絞り込めます
depot ci ssh	実行中のジョブのサンドボックスに対話型ターミナルで接続します
depot ci cancel	実行全体、ワークフロー、または単一のジョブをキャンセルします
depot ci rerun	ワークフロー内の終了状態にあるすべてのジョブを再実行します
depot ci retry	失敗またはキャンセルされたジョブを 1 件再試行します。--failed を指定すると、後続のジョブも再実行します

完全なフラグ一覧、JSON 出力形式、または上記のトリアージ例にないコマンドについては、references/runs-and-debugging.md を参照してください。

テスト結果と実行時間に基づく分割

depot tests を使って、解析済みの JUnit 結果を確認します。depot tests split、depot tests run、または depot tests report を使うと、過去の実行時間に基づいてテストを均等に分割し、新しいレポートをアップロードできます。これら 3 つのサブコマンドは、Depot CI または Depot GitHub Actions ランナージョブ内でのみ実行されます。

候補の識別ルール、マトリックスの動作、レポートの要件、コマンド例については、references/test-splitting.md を参照してください。

GitHub Actions との互換性

Depot CI は GitHub Actions の YAML ワークフローを実行します。完全には互換でない部分がいくつかあります。サポート状況と互換性の一覧については、references/github-actions-compatibility.md を参照してください。

次のような質問への回答や作業が必要な場合は、互換性リファレンスを確認してください。

• concurrency、jobs.<id>.environment、jobs.<id>.snapshot、jobs.<id>.container、jobs.<id>.services、jobs.<id>.strategy.matrix、steps[*].shell など、ワークフロー、ジョブ、ステップの各レベルのフィールドがサポートされているかどうか。
• トリガーイベントが受け付けられるかどうか。サポートされているイベント（push、pull_request、pull_request_target、pull_request_review、pull_request_review_comment、issue_comment、deployment_status、repository_dispatch、schedule、workflow_call、workflow_dispatch、workflow_run、merge_group）と、Depot CI が拒否する GitHub 専用イベント（例：release、issues、deployment、branch_protection_rule）。
• 利用可能な式のコンテキスト（github、env、vars、secrets、needs、strategy、matrix、steps、job、runner、inputs、depot）と関数（always()、success()、failure()、cancelled()、case()、contains()、startsWith()、endsWith()、format()、join()、toJSON()、fromJSON()、hashFiles()）。
• 動作する permissions のスコープ（actions、checks、code-quality、contents、id-token、issues、packages、pull-requests、security-events、statuses）。read-all と write-all には含まれないため、code-quality は明示的にリクエストしてください。
• 実行されるアクションの種類（JavaScript Node 12/16/20/24、Composite、Docker）。
• Depot CI がサポートする runs-on の Depot ランナーラベルとサンドボックスサイズ（x86_64 と Arm のみ。macOS と Windows は非対応）、および認識されないラベルの扱い。
• depot ci migrate によってジョブが自動的に無効化された、on: からトリガーが削除された、または runs-on ラベルが再マッピングされた理由の調査。
• サポートされている参照とリポジトリアクセスを使用した、リポジトリをまたぐ再利用可能なワークフローの呼び出し。
• サポート対象外の機能（フォークによってトリガーされる PR、デプロイ環境）に対する回避策の推奨。

特定の GHA 機能に依存しない通常の移行、実行、シークレット、デバッグの作業では、references/github-actions-compatibility.md を読み込む必要はありません。

ディレクトリ構成

your-repo/
├── .github/
│   ├── workflows/     # Original GHA workflows (keep running)
│   └── actions/       # Local composite actions
├── .depot/
│   ├── workflows/     # Depot CI copies of workflows
│   └── actions/       # Depot CI copies of local actions

よくある間違い

間違い	修正方法
移行後に .github/workflows/ を削除する	Depot CI との同等性を確認できるよう、移行期間中はそのまま残します
リポジトリをまたぐ再利用可能なワークフローにブランチ参照を使用する	完全なコミット SHA またはサポート対象のバージョンタグを使用します。互換性リファレンスを参照してください
ブランチや環境のバリエーションにはダッシュボードが必要だと思い込む	CLI で --repo／--env／--branch／--workflow セレクターを使ってバリエーションを直接管理できます
間違った組織のコンテキストで実行する	depot org show を確認し、depot org list で一覧表示してから、組織を切り替えるか --org <id> を渡します
複数の組織があるのに --org フラグを忘れる	移行または実行コマンドで想定したリポジトリやワークフローが対象にならない場合があります。--org <id> を指定してください
Windows または macOS のランナーラベルを使用する	Depot CI は Ubuntu サンドボックスをサポートしています。移行前に、互換性のあるジョブとランナーを選択してください