I read through both files in full and the strategy is sound and consistently implemented.
What this does: All PR and merge-queue runs are handed off to Depot CI (.depot/workflows/test.yml), while .github/workflows/test.yml is stripped to workflow_call only — keeping release.yml able to run the full suite on main/tag builds inside GitHub Actions. The Depot file is a faithful copy with runner labels swapped and the pull_request + merge_group triggers moved there.
Things I checked specifically:
Concurrency group names. Both files use the same ${{ github.workflow }}-${{ github.ref }} group. Since the two workflows will have different github.workflow values (they have the same name: Test but live in different workflow files), GitHub treats them as distinct workflow runs. This is intentional — the Depot run and the workflow_call run never need to cancel each other.
The changes filter regex update (.github/workflows/test.yml line 123, .depot/workflows/test.yml line 136) now includes \.depot/workflows/test\.yml so that touching the new Depot workflow itself triggers the distributed suite on the PR that introduces it. That's the right defensive move.
workflow_call coverage. The GitHub copy retains all the same job logic, just without PR/MQ triggers. The build job in both copies correctly guards if: github.event_name != 'workflow_call', so release.yml's call won't double-build. Jobs that are lightweight (changes, test-groups, blackbox-groups, blackbox-groups-distributed) still use ubuntu-latest in the GitHub copy — that's fine since those jobs run only on workflow_call now and don't need Depot.
Gate integrity in the test summary job. It requires test-runner and changes to succeed outright, accepts skipped for test-blackbox* (fork PRs) and for test-blackbox-distributed (non-distributed PRs), and fails on any non-success/non-skipped result from the matrix builder jobs. The logic is the same in both files and matches the pre-existing GitHub Actions version — no coverage holes introduced.
No secrets, hardcoded tokens, or new injection surfaces. The CLOUD_REPO_TOKEN usage was already present in the original.
This draft looks ready to graduate to human review. The intent is clearly scoped (canary, not a permanent replacement), the comment at the top of the Depot file says so explicitly, and the mechanism for winding it down is obvious — flip the triggers back.
Verdict: ready
{
"owner": "mirendev",
"repo": "runtime",
"number": 1147,
"verdict": "ready",
"event": "comment",
"summary": "I read through both files in full and the strategy is sound and consistently implemented.\n\n**What this does:** All PR and merge-queue runs are handed off to Depot CI (`.depot/workflows/test.yml`), while `.github/workflows/test.yml` is stripped to `workflow_call` only — keeping `release.yml` able to run the full suite on main/tag builds inside GitHub Actions. The Depot file is a faithful copy with runner labels swapped and the `pull_request` + `merge_group` triggers moved there.\n\n**Things I checked specifically:**\n\n- **Concurrency group names.** Both files use the same `${{ github.workflow }}-${{ github.ref }}` group. Since the two workflows will have different `github.workflow` values (they have the same `name: Test` but live in different workflow files), GitHub treats them as distinct workflow runs. This is intentional — the Depot run and the workflow_call run never need to cancel each other.\n\n- **The `changes` filter regex update** (`.github/workflows/test.yml` line 123, `.depot/workflows/test.yml` line 136) now includes `\\.depot/workflows/test\\.yml` so that touching the new Depot workflow itself triggers the distributed suite on the PR that introduces it. That's the right defensive move.\n\n- **`workflow_call` coverage.** The GitHub copy retains all the same job logic, just without PR/MQ triggers. The `build` job in both copies correctly guards `if: github.event_name != 'workflow_call'`, so release.yml's call won't double-build. Jobs that are lightweight (`changes`, `test-groups`, `blackbox-groups`, `blackbox-groups-distributed`) still use `ubuntu-latest` in the GitHub copy — that's fine since those jobs run only on `workflow_call` now and don't need Depot.\n\n- **Gate integrity in the `test` summary job.** It requires `test-runner` and `changes` to succeed outright, accepts `skipped` for `test-blackbox*` (fork PRs) and for `test-blackbox-distributed` (non-distributed PRs), and fails on any non-success/non-skipped result from the matrix builder jobs. The logic is the same in both files and matches the pre-existing GitHub Actions version — no coverage holes introduced.\n\n- **No secrets, hardcoded tokens, or new injection surfaces.** The `CLOUD_REPO_TOKEN` usage was already present in the original.\n\nThis draft looks ready to graduate to human review. The intent is clearly scoped (canary, not a permanent replacement), the comment at the top of the Depot file says so explicitly, and the mechanism for winding it down is obvious — flip the triggers back.",
"posted_to_pr": true,
"draft": true
}