Wait for a Depot CI run or workflow to finish
depot_wait_for_ci_runWait for a Depot CI run or workflow to reach a terminal state, then report the outcome and node changes. Polls until completion, timeout, or a specified job finishes.
Instructions
Wait, for a bounded time, until a Depot CI run, one workflow in it, or one job reaches a terminal state, then report the outcome and which nodes changed state while waiting.
Use this after a push or a rerun when the next step depends on the result: "wait for the run to finish, then diagnose it if it failed". Pass runId to watch a whole run. Pass workflowId to watch one workflow: this is what to do after depot_rerun_ci_workflow or depot_retry_ci_failed_jobs, which start a new execution of the same workflow rather than a new run; the wait ends when the latest execution is terminal. With both ids the workflow is watched and must belong to that run. Pass untilJobKey to return as soon as one job is done instead of the whole target, for example the test job when the deploy job behind it does not matter yet.
This is bounded polling, not a stream. It calls GetRunStatus (or GetWorkflow) every pollSeconds until the target is finished, failed, or cancelled, or until timeoutSeconds is spent, whichever comes first, then returns. It never subscribes to Depot's log or status streams. If the result says timedOut=true the target is still going: call this tool again with the same id to keep waiting; the changes list shows what moved in the meantime. Keep timeoutSeconds below your MCP client's own tool-call timeout, or the client will give up before this tool does.
A run or workflow that is already finished returns immediately after one poll, so this is also a cheap way to check "is it done yet". For the structure use depot_get_ci_run or depot_get_ci_workflow; for why it failed use depot_diagnose_ci_failure.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| runId | No | The run id to wait on, as returned by depot_list_ci_runs. Required unless workflowId is given; with workflowId it is only cross-checked. | |
| workflowId | No | Wait for this workflow instead of a whole run, as shown by depot_get_ci_run (workflowId=...) or returned by depot_rerun_ci_workflow. The wait ends when its latest execution is terminal. | |
| pollSeconds | No | Seconds between status requests, 2 to 30. Each poll is one request to Depot; lower values give faster answers at the cost of more requests. | |
| untilJobKey | No | Return as soon as this job reaches a terminal state, even if the run or workflow is still going. Accepts the job key, display name, or job id as shown by depot_get_ci_run. | |
| timeoutSeconds | No | Longest this call may wait, 5 to 300 seconds. On expiry the tool returns timedOut=true rather than an error; call again to keep waiting. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job | No | The job named by untilJobKey, when it was found. | |
| notes | Yes | ||
| polls | Yes | ||
| runId | No | ||
| failed | Yes | True when the target ended in failed or cancelled. | |
| status | No | Status of the watched run, or of the latest execution of the watched workflow, at the last poll. | |
| changes | Yes | Nodes whose state differs between the first and last poll. | |
| outcome | Yes | Why the wait ended: the run finished, the workflow (its latest execution) finished, the named job finished, or the timeout expired. | |
| jobCount | Yes | ||
| timedOut | Yes | ||
| execution | No | When watching a workflow: which execution the wait followed. | |
| workflowId | No | Present when a workflow was watched. | |
| pollSeconds | Yes | ||
| initialStatus | No | The same status at the first poll. | |
| elapsedSeconds | Yes | ||
| failedJobCount | Yes | ||
| timeoutSeconds | Yes |