人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读github.get_job_logs是 IronClaw 开源仓库中 GitHub 扩展包extension id:github提供的一个模型可见工具用于按Job粒度拉取 GitHub Actions 的纯文本执行日志——当一次 CI 运行失败时它是定位具体编译器报错、失败测试、lint 消息与 action 输出的第一手数据源。本文将围绕该工具从输入参数、调用方式、底层 WASM 实现到重定向与凭据安全机制展开完整解析读完你可以直接在 IronClaw 的 Agent 会话中用它完成查日志 → 定位失败 → 修复 → 重跑的闭环 CI 排障。一、工具定位为什么按 Job 而不是按 Run 取日志原文档开宗明义该工具获取的是单个 GitHub Actions Job而非整个 Run的纯文本日志。之所以强调这一点是因为 GitHub 的 REST 接口中Run 与 Job 是两个不同粒度的资源Runworkflow run一次 workflow 触发产生的整体执行可能包含多个并行 jobJobworkflow jobrun 内的一个具体任务拥有独立的id、状态queued/in_progress/completed与独立的日志流。在 CI 排障场景下run 级状态只能告诉你整体红没红而真正需要分析的是失败那个 job 的日志内容——具体的编译错误、测试断言失败或 lint 警告都沉淀在 job 日志里。因此github.get_job_logs的定位就是在决定如何修复之前先回答为什么失败。其输入输出契约非常精简Inputowner、repo、job_id三个字段Output原始日志文本plain-text log body。二、输入参数详解与 JSON Schema 约束工具的输入契约由 get_job_logs.input.v1.json 定义三个字段全部必填required: [owner, repo, job_id]且additionalProperties: false禁止任何多余字段。逐字段约束如下字段类型约束说明ownerstringminLength: 1、maxLength: 100、pattern: ^[^\s/?#]$、禁止匹配..仓库所属用户或组织名不允许空白、路径分隔符及查询字符repostring同上仓库名约束与owner一致job_idintegerminimum: 1GitHub Actions job 的数字 ID来自github.get_workflow_run_jobs返回的每个 job 的id这些约束在 WASM 侧并非摆设。查看 actions.rs 中get_job_logs的实现可以看到它首先调用validate_path_segment(owner)与validate_path_segment(repo)做防御性校验。validation.rs 中该函数拒绝空字符串、包含/、..、?、#以及任何控制字符或空白字符的输入——这与 JSON Schema 中的pattern与not约束一一对应防止通过路径段注入拼出非预期 URL。随后url_encode_path会对 owner/repo 做百分号编码除字母、数字、-、_、.外全部转义再拼接请求路径。三、典型调用流程job_id 从哪来原文档明确指出job_id来自github.get_workflow_run_jobs每个 job 的id。因此一个完整的工作流应该是定位失败 run使用github.get_workflow_runs按仓库可按branch、event、status等过滤找到目标 workflow run枚举 run 下的 job使用github.get_workflow_run_jobs参数owner、repo、run_id可选filter、page、limit列出该 run 下所有 job从中取出conclusion failure或status completed的 job 的id拉取失败 job 日志将job_id传给github.get_job_logs获得纯文本日志分析并修复从日志中提取具体错误修改代码或配置后可用github.rerun_workflow_job重跑单个 job或github.rerun_failed_workflow_run_jobs重跑 run 内所有失败 job验证修复。注意日志仅在 GitHub 保留有限期限retention 到期即不可再取因此排查应尽快进行。由于该工具按 job 粒度取日志避免了拉取整个 run 的日志带来的大量冗余 token 消耗属于按需、精准的读取型工具。四、底层实现原理WASM 中的执行链GitHub 扩展包是一个纯数据型data-only包不含 Rust crate行为以 WASM guest 形式随仓库提交guest 源码位于 wasm-src/。github.get_job_logs的完整执行链如下工具分发dispatch.rs 中GitHubAction::GetJobLogs { owner, repo, job_id }分支将参数解构后调用get_job_logs(owner, repo, job_id)参数类型types.rs 中GetJobLogs变体的job_id字段类型为u64与输入 schema 中integer类型对应HTTP 请求actions.rs 拼接路径/repos/{owner}/{repo}/actions/jobs/{job_id}/logs并发出GET请求最终经github_request通过 host 的http_request能力带Accept: application/vnd.githubjson、X-GitHub-Api-Version与User-Agent头超时 10 秒发送到https://api.github.com响应处理2xx 时返回响应体字符串非 2xx 时映射为稳定错误码详见下文错误处理。五、302 重定向与凭据安全日志如何从 blob 存储取回这是原文档重点说明、也最容易被忽略的机制。GitHub 的 job logs 端点并不会直接返回日志内容而是302 重定向到一个短期有效的预签名下载 URL从 manifest.toml 的注释可以看到典型目标是*.blob.core.windows.net这样的 Azure blob 存储地址。原文档强调host 会替你跟随该重定向并返回日志正文你无需自行抓取任何二级 URL——这正是 IronClaw 架构中 host egress 层替 WASM guest 承担的安全职责。其安全设计在 manifest 中有完整体现重定向跟随由 host 完成guest 只需请求一次host egress 跟随 302且在跳转到 blob 存储时剥离Authorization头、去除凭据确保 GitHub token 永远不会被发送到 blob 存储域名目标域名显式白名单manifest 中为该工具声明了network_targets [{ scheme https, host_pattern *.blob.core.windows.net }]即 host 只在重定向目标命中该白名单时才放行凭据注入范围github_runtime_token仅注入到api.github.comaudience { scheme https, host api.github.com }以Authorization: token GH_TOKEN头形式注入占位环境变量GH_TOKENblob 存储主机不注入任何凭据。六、输出格式为什么日志被 JSON 编码原文档说返回原始日志文本但这一描述在实现层面有一个重要细节。WASM 工具 ABI 要求output必须是合法 JSON 文档host 用serde_json::from_str解码非 JSON 会触发OutputDecode错误而 GitHub 的日志正文是纯文本、不是 JSON。因此 actions.rs 中的实现会先将原始日志文本serde_json::to_string编码为一个 JSON 字符串值再返回——这正是该工具在 manifest.toml 中声明output_schema_ref schemas/github/raw_output.v1.json的原因该 schemaraw_output.v1.json允许object | array | string | null四种形态恰好容纳裸字符串形态的日志输出。源码注释也特别提醒其他端点返回的本来就是 JSON body不得二次编码唯独日志端点需要这一层包装。对 Agent 侧而言最终拿到的是解包后的纯文本日志可直接用于分析具体编译器报错、失败测试或 lint 信息无需任何二次抓取。七、错误处理与失败语义github_requestrequest.rs对日志端点的非 2xx 响应做了统一归一化映射为稳定错误码401→ 捕获 provider 返回的message截断至 512 字符见MAX_PROVIDER_MESSAGE_CHARS并附加到 guest 错误信封中供 host 带到 auth 门控链路做需要授权诊断422且响应体为 GitHub Validation Failed 形态 →github_api_error_status_422_validation其他状态码 →github_api_error_status_{status}host 层故障网络拒绝、输出过大、执行器失败等→ 对应的AuthRequired/github_api_egress_denied/github_api_body_limit等错误码。常见失败场景及对策场景现象对策job_id不属于该仓库404 / 对应错误码重新用github.get_workflow_run_jobs确认 job id 与 run 的对应关系日志已过保留期404 / 日志不可得日志仅保留有限时间需在保留期内排查凭据无效或过期401 Bad credentials检查github_runtime_token配置参考 manifest.toml 中[auth.github]的校验方式GEThttps://api.github.com/user期望 200日志体过大github_api_body_limit考虑改用按 job 拉取或控制输出范围八、权限模型读取型工具的安全边界在 manifest.toml 中github.get_job_logs的权限配置为default_permission allow与effects只含[network, use_secret]的只读属性匹配——它只发起网络请求并使用凭据不产生任何外部写操作因此默认放行visibility model对模型可见origin_gate_matrix { loop_run gated_unless_granted, product forbidden, automation forbidden }与其他 GitHub 工具一致在 product 与 automation 入口被禁止仅在 loop_run 场景按门控策略放行effects声明为network出网与use_secret使用 GitHub token这是该包所有网络型工具的通用标注。对比同一包内的写操作工具如github.create_issue、github.rerun_workflow_job等均声明external_write且default_permission ask可以清晰看到 IronClaw 的权限设计原则读日志默认允许写操作需要显式确认。这也意味着在 Agent 自主排障场景中拉取日志通常不需要额外授权而修复后的重跑动作则会触发确认流程。九、实战一段完整的 CI 排障循环综合上述能力一个可复用的 IronClaw Agent 排障循环如下用github.get_workflow_runs找到目标分支上最近失败的 run用github.get_workflow_run_jobs拿到该 run 下所有 job 及各自id、conclusion对失败的 job 调用github.get_job_logs取得纯文本日志从日志中定位具体错误编译错误、测试失败、lint 告警、action 输出修复后调用github.rerun_workflow_job单独重跑该 job或github.rerun_failed_workflow_run_jobs重跑所有失败 job进入下一轮验证。整个闭环全部落在 GitHub 扩展包的 Actions 相关工具族内actions.rs相关工具定义与 prompt 文档可在 crates/extensions/packages/github/prompts/github/ 目录下逐一查阅如 get_workflow_run_jobs.md、get_workflow_runs.md、rerun_workflow_job.md。十、扩展包背景与后续深入路径github.get_job_logs是 GitHub 扩展包 49 个工具github.get_repo到github.handle_webhook之一。该包是仓库中工具面最大的扩展覆盖仓库、Issue、PR、评审、文件、Release、workflow、fork 与 webhook 能力版本为0.2.8运行时为 WASM制品提交在 wasm/github_tool.wasm被 ironclaw_extension_support/src/packages/github.rs 内嵌使用。包级说明见 packages/github/README.md扩展家族模型与包规则见 crates/extensions/AGENTS.md。若想继续深入可以从三条路径入手manifest 投影测试运行cargo test -p ironclaw_extension_registry验证工具清单与 schema 引用的一致性WASM 制品新鲜度检查python3 scripts/ci/check-wasm-artifact-freshness.py可校验已提交的 WASM 制品与 guest 源码是否同步重新构建需./scripts/build-wasm-extensions.sh --first-party后--updateguest 源码阅读wasm-src/src/ 下的actions.rs、request.rs、validation.rs、dispatch.rs、types.rs构成了理解该工具全部行为的最小代码集。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw GitHub 扩展实战使用 github.get_workflow_run_jobs 查询 GitHub Actions 工作流运行任务IronClaw GitHub 扩展实战使用 github.get_workflow_run_jobs 查询 GitHub Actions 工作流运行任务 本人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展github.list_pull_requests 拉取请求列表能力实战指南IronClaw GitHub 扩展github.list_pull_requests 拉取请求列表能力实战指南 本文聚焦 IronClaw 扩展目录中的 g人工智能AI 应用交互助手AI AgentDownKyi完整使用指南B站视频下载的终极解决方案DownKyi完整使用指南B站视频下载的终极解决方案 哔哩下载姬DownKyi是一款专为B站用户打造的开源视频下载工具支持从标清到8K超高清的全画质解析人工智能AI 应用交互助手AI Agent上一篇Thumbnailator内存管理终极指南大图片处理的高效优化策略下一篇Fluence Rewards项目量子引力签名时空弯曲生成的唯一标识创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 IronClaw GitHub 扩展：get_job_logs 工作日志获取工具的实战指南
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读github.get_job_logs是 IronClaw 开源仓库中 GitHub 扩展包extension id:github提供的一个模型可见工具用于按Job粒度拉取 GitHub Actions 的纯文本执行日志——当一次 CI 运行失败时它是定位具体编译器报错、失败测试、lint 消息与 action 输出的第一手数据源。本文将围绕该工具从输入参数、调用方式、底层 WASM 实现到重定向与凭据安全机制展开完整解析读完你可以直接在 IronClaw 的 Agent 会话中用它完成查日志 → 定位失败 → 修复 → 重跑的闭环 CI 排障。一、工具定位为什么按 Job 而不是按 Run 取日志原文档开宗明义该工具获取的是单个 GitHub Actions Job而非整个 Run的纯文本日志。之所以强调这一点是因为 GitHub 的 REST 接口中Run 与 Job 是两个不同粒度的资源Runworkflow run一次 workflow 触发产生的整体执行可能包含多个并行 jobJobworkflow jobrun 内的一个具体任务拥有独立的id、状态queued/in_progress/completed与独立的日志流。在 CI 排障场景下run 级状态只能告诉你整体红没红而真正需要分析的是失败那个 job 的日志内容——具体的编译错误、测试断言失败或 lint 警告都沉淀在 job 日志里。因此github.get_job_logs的定位就是在决定如何修复之前先回答为什么失败。其输入输出契约非常精简Inputowner、repo、job_id三个字段Output原始日志文本plain-text log body。二、输入参数详解与 JSON Schema 约束工具的输入契约由 get_job_logs.input.v1.json 定义三个字段全部必填required: [owner, repo, job_id]且additionalProperties: false禁止任何多余字段。逐字段约束如下字段类型约束说明ownerstringminLength: 1、maxLength: 100、pattern: ^[^\s/?#]$、禁止匹配..仓库所属用户或组织名不允许空白、路径分隔符及查询字符repostring同上仓库名约束与owner一致job_idintegerminimum: 1GitHub Actions job 的数字 ID来自github.get_workflow_run_jobs返回的每个 job 的id这些约束在 WASM 侧并非摆设。查看 actions.rs 中get_job_logs的实现可以看到它首先调用validate_path_segment(owner)与validate_path_segment(repo)做防御性校验。validation.rs 中该函数拒绝空字符串、包含/、..、?、#以及任何控制字符或空白字符的输入——这与 JSON Schema 中的pattern与not约束一一对应防止通过路径段注入拼出非预期 URL。随后url_encode_path会对 owner/repo 做百分号编码除字母、数字、-、_、.外全部转义再拼接请求路径。三、典型调用流程job_id 从哪来原文档明确指出job_id来自github.get_workflow_run_jobs每个 job 的id。因此一个完整的工作流应该是定位失败 run使用github.get_workflow_runs按仓库可按branch、event、status等过滤找到目标 workflow run枚举 run 下的 job使用github.get_workflow_run_jobs参数owner、repo、run_id可选filter、page、limit列出该 run 下所有 job从中取出conclusion failure或status completed的 job 的id拉取失败 job 日志将job_id传给github.get_job_logs获得纯文本日志分析并修复从日志中提取具体错误修改代码或配置后可用github.rerun_workflow_job重跑单个 job或github.rerun_failed_workflow_run_jobs重跑 run 内所有失败 job验证修复。注意日志仅在 GitHub 保留有限期限retention 到期即不可再取因此排查应尽快进行。由于该工具按 job 粒度取日志避免了拉取整个 run 的日志带来的大量冗余 token 消耗属于按需、精准的读取型工具。四、底层实现原理WASM 中的执行链GitHub 扩展包是一个纯数据型data-only包不含 Rust crate行为以 WASM guest 形式随仓库提交guest 源码位于 wasm-src/。github.get_job_logs的完整执行链如下工具分发dispatch.rs 中GitHubAction::GetJobLogs { owner, repo, job_id }分支将参数解构后调用get_job_logs(owner, repo, job_id)参数类型types.rs 中GetJobLogs变体的job_id字段类型为u64与输入 schema 中integer类型对应HTTP 请求actions.rs 拼接路径/repos/{owner}/{repo}/actions/jobs/{job_id}/logs并发出GET请求最终经github_request通过 host 的http_request能力带Accept: application/vnd.githubjson、X-GitHub-Api-Version与User-Agent头超时 10 秒发送到https://api.github.com响应处理2xx 时返回响应体字符串非 2xx 时映射为稳定错误码详见下文错误处理。五、302 重定向与凭据安全日志如何从 blob 存储取回这是原文档重点说明、也最容易被忽略的机制。GitHub 的 job logs 端点并不会直接返回日志内容而是302 重定向到一个短期有效的预签名下载 URL从 manifest.toml 的注释可以看到典型目标是*.blob.core.windows.net这样的 Azure blob 存储地址。原文档强调host 会替你跟随该重定向并返回日志正文你无需自行抓取任何二级 URL——这正是 IronClaw 架构中 host egress 层替 WASM guest 承担的安全职责。其安全设计在 manifest 中有完整体现重定向跟随由 host 完成guest 只需请求一次host egress 跟随 302且在跳转到 blob 存储时剥离Authorization头、去除凭据确保 GitHub token 永远不会被发送到 blob 存储域名目标域名显式白名单manifest 中为该工具声明了network_targets [{ scheme https, host_pattern *.blob.core.windows.net }]即 host 只在重定向目标命中该白名单时才放行凭据注入范围github_runtime_token仅注入到api.github.comaudience { scheme https, host api.github.com }以Authorization: token GH_TOKEN头形式注入占位环境变量GH_TOKENblob 存储主机不注入任何凭据。六、输出格式为什么日志被 JSON 编码原文档说返回原始日志文本但这一描述在实现层面有一个重要细节。WASM 工具 ABI 要求output必须是合法 JSON 文档host 用serde_json::from_str解码非 JSON 会触发OutputDecode错误而 GitHub 的日志正文是纯文本、不是 JSON。因此 actions.rs 中的实现会先将原始日志文本serde_json::to_string编码为一个 JSON 字符串值再返回——这正是该工具在 manifest.toml 中声明output_schema_ref schemas/github/raw_output.v1.json的原因该 schemaraw_output.v1.json允许object | array | string | null四种形态恰好容纳裸字符串形态的日志输出。源码注释也特别提醒其他端点返回的本来就是 JSON body不得二次编码唯独日志端点需要这一层包装。对 Agent 侧而言最终拿到的是解包后的纯文本日志可直接用于分析具体编译器报错、失败测试或 lint 信息无需任何二次抓取。七、错误处理与失败语义github_requestrequest.rs对日志端点的非 2xx 响应做了统一归一化映射为稳定错误码401→ 捕获 provider 返回的message截断至 512 字符见MAX_PROVIDER_MESSAGE_CHARS并附加到 guest 错误信封中供 host 带到 auth 门控链路做需要授权诊断422且响应体为 GitHub Validation Failed 形态 →github_api_error_status_422_validation其他状态码 →github_api_error_status_{status}host 层故障网络拒绝、输出过大、执行器失败等→ 对应的AuthRequired/github_api_egress_denied/github_api_body_limit等错误码。常见失败场景及对策场景现象对策job_id不属于该仓库404 / 对应错误码重新用github.get_workflow_run_jobs确认 job id 与 run 的对应关系日志已过保留期404 / 日志不可得日志仅保留有限时间需在保留期内排查凭据无效或过期401 Bad credentials检查github_runtime_token配置参考 manifest.toml 中[auth.github]的校验方式GEThttps://api.github.com/user期望 200日志体过大github_api_body_limit考虑改用按 job 拉取或控制输出范围八、权限模型读取型工具的安全边界在 manifest.toml 中github.get_job_logs的权限配置为default_permission allow与effects只含[network, use_secret]的只读属性匹配——它只发起网络请求并使用凭据不产生任何外部写操作因此默认放行visibility model对模型可见origin_gate_matrix { loop_run gated_unless_granted, product forbidden, automation forbidden }与其他 GitHub 工具一致在 product 与 automation 入口被禁止仅在 loop_run 场景按门控策略放行effects声明为network出网与use_secret使用 GitHub token这是该包所有网络型工具的通用标注。对比同一包内的写操作工具如github.create_issue、github.rerun_workflow_job等均声明external_write且default_permission ask可以清晰看到 IronClaw 的权限设计原则读日志默认允许写操作需要显式确认。这也意味着在 Agent 自主排障场景中拉取日志通常不需要额外授权而修复后的重跑动作则会触发确认流程。九、实战一段完整的 CI 排障循环综合上述能力一个可复用的 IronClaw Agent 排障循环如下用github.get_workflow_runs找到目标分支上最近失败的 run用github.get_workflow_run_jobs拿到该 run 下所有 job 及各自id、conclusion对失败的 job 调用github.get_job_logs取得纯文本日志从日志中定位具体错误编译错误、测试失败、lint 告警、action 输出修复后调用github.rerun_workflow_job单独重跑该 job或github.rerun_failed_workflow_run_jobs重跑所有失败 job进入下一轮验证。整个闭环全部落在 GitHub 扩展包的 Actions 相关工具族内actions.rs相关工具定义与 prompt 文档可在 crates/extensions/packages/github/prompts/github/ 目录下逐一查阅如 get_workflow_run_jobs.md、get_workflow_runs.md、rerun_workflow_job.md。十、扩展包背景与后续深入路径github.get_job_logs是 GitHub 扩展包 49 个工具github.get_repo到github.handle_webhook之一。该包是仓库中工具面最大的扩展覆盖仓库、Issue、PR、评审、文件、Release、workflow、fork 与 webhook 能力版本为0.2.8运行时为 WASM制品提交在 wasm/github_tool.wasm被 ironclaw_extension_support/src/packages/github.rs 内嵌使用。包级说明见 packages/github/README.md扩展家族模型与包规则见 crates/extensions/AGENTS.md。若想继续深入可以从三条路径入手manifest 投影测试运行cargo test -p ironclaw_extension_registry验证工具清单与 schema 引用的一致性WASM 制品新鲜度检查python3 scripts/ci/check-wasm-artifact-freshness.py可校验已提交的 WASM 制品与 guest 源码是否同步重新构建需./scripts/build-wasm-extensions.sh --first-party后--updateguest 源码阅读wasm-src/src/ 下的actions.rs、request.rs、validation.rs、dispatch.rs、types.rs构成了理解该工具全部行为的最小代码集。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw GitHub 扩展实战使用 github.get_workflow_run_jobs 查询 GitHub Actions 工作流运行任务IronClaw GitHub 扩展实战使用 github.get_workflow_run_jobs 查询 GitHub Actions 工作流运行任务 本人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展github.list_pull_requests 拉取请求列表能力实战指南IronClaw GitHub 扩展github.list_pull_requests 拉取请求列表能力实战指南 本文聚焦 IronClaw 扩展目录中的 g人工智能AI 应用交互助手AI AgentDownKyi完整使用指南B站视频下载的终极解决方案DownKyi完整使用指南B站视频下载的终极解决方案 哔哩下载姬DownKyi是一款专为B站用户打造的开源视频下载工具支持从标清到8K超高清的全画质解析人工智能AI 应用交互助手AI Agent上一篇Thumbnailator内存管理终极指南大图片处理的高效优化策略下一篇Fluence Rewards项目量子引力签名时空弯曲生成的唯一标识创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考