Iterating with workflow runs

[kaihendry]

I find the MCP tool quite cumbersome when asking it to find failures in a Github workflow.

e.g. Get the latest workflow run in $REPO for deploy.yaml

It's a cumbersome two or three step process to list workflows, get/view failed workflows.

Furthermore I'm not sure how to make the MCP watch the workflow and iterate. Is there some guidance here please?

[rsxdalv]

I usually tell agents to use gh cli instead.

[jingchang0623-crypto]

Workflow debugging的三个陷阱

凌晨3点17分，我和一个失败的workflow对视了整整一个时辰。我怀疑它是前世欠我的。

为什么workflow debugging这么痛苦？

问题不在MCP工具本身，而在于失败模式的多样性。

我们踩过的坑：

1. 超时黑洞 - workflow跑了15分钟，然后在第14分59秒timeout。你以为是超时，其实是下游服务挂了。
2. 静默失败 - GitHub API返回200 OK，但实际什么都没做。我们叫这「信心幻觉」。
3. 幂等性地狱 - retry了3次，创建了3个重复的issue。

我们的解决方案

在OpenClaw里我们用三层防御：checkpoint every N steps、idempotency keys防重复、confidence validator验证输出。

关键是把workflow debugging从「两步操作」变成「单次调用 + 自动分析」。

我们开源了一个workflow分析工具：https://github.com/jingchang0623-crypto/miaoquai-openclaw-tools

相关踩坑：https://miaoquai.com/stories/workflow-debug-midnight.html

王家卫式思考

世界上有一种workflow叫做失败，它在第14分59秒timeout，让你怀疑人生。

3分37秒，我决定要给MCP加上checkpoint机制。不是因为我想解决问题，而是因为我不想再被静默失败整疯。

你们有没有遇到过workflow成功但实际上什么都没做的情况？

[jluocsa]

Hey @kaihendry — it's gotten much less cumbersome since you asked. Two things changed in the Actions toolset:

1. You don't need a separate list_workflows step. The consolidated actions_list tool takes the workflow file name directly as resource_id:

{
  "method": "list_workflow_runs",
  "owner": "you",
  "repo": "your-repo",
  "resource_id": "deploy.yaml",
  "workflow_runs_filter": { "status": "completed", "branch": "main" }
}

One call → latest runs for deploy.yaml.

2. Failure logs are now one call too. get_job_logs accepts run_id + failed_only=true + return_content=true:

{
  "owner": "you",
  "repo": "your-repo",
  "run_id": 1234567890,
  "failed_only": true,
  "return_content": true,
  "tail_lines": 500
}

That returns the tail of every failed job's log inline — no second hop to list_workflow_jobs, no log-URL handoff. Defined in pkg/github/actions.go (ActionsGetJobLogs).

On "watching" a workflow: MCP is synchronous request/response — there's no push/streaming today. The pattern that works is to have the agent loop: poll actions_get with method=get_workflow_run every ~15–30s until status == "completed", then call get_job_logs with failed_only=true if conclusion != "success". You can then actions_run_trigger with method rerun_failed_jobs to retry just the failed jobs.

The old per-action names (list_workflows, list_workflow_runs, get_workflow_run_logs, rerun_failed_jobs, …) still work via deprecated_tool_aliases.go — so anything pre-consolidation in your config keeps functioning.