嵌入式物联网硬件开发驱动开发【免费下载链接】FastLEDThe FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r Wed like to use github issues just for tracking library bugs / enhancements.项目地址https://gitcode.com/gh_mirrors/fa/FastLED点击查看免费下载本文以 FastLED 仓库内置的 gh-healthcheck 技能定义 及其背后实现 ci/tools/gh/gh_healthcheck.py 为主线讲解如何对 GitHub Actions 工作流做快速健康检查一次命令拿到整体 CI 状态、失败 job 清单、按类别聚合的根因分析Missing Header、Linker Error、Platform Resolution 等以及可落地的修复建议。读完本文你将掌握uv run ci/tools/gh/gh_healthcheck.py的完整用法、三个详情级别low / medium / high的取舍以及读懂健康报告与退出码含义的能力并理解其底层的日志抓取与错误分类实现原理。gh-healthcheck 是什么面向 fork 场景的 CI 快速体检FastLED 是一个多平台Arduino、ESP32、RP2040、STM32 等彩色 LED 动画库其 build.yml 汇聚了大量平台构建 job一次 push 或 PR 可能触发数十个并行构建。当 CI 变红时逐个 job 翻日志效率很低且多人协作的 fork 场景下经常需要快速判断这次失败是普遍性的还是某个平台特有的。gh-healthcheck正是为此设计的 Claude Code Skill定义于 .claude/skills/gh-healthcheck/SKILL.md声明context: fork说明它主要服务于 fork 分支上的 CI 状态快速概览与模式分析。它的核心能力一句话概括Analyze GitHub Actions workflow health and provide a comprehensive diagnostic report——获取工作流运行数据聚合所有失败 job 的错误按根因类别分组输出诊断报告与修复建议。技能内部的实际执行只有一条命令uv run ci/tools/gh/gh_healthcheck.py $ARGUMENTS其中$ARGUMENTS是调用时传入的参数原样透传。也就是说这个 Skill 是对 ci/tools/gh/gh_healthcheck.py 这一 Python 工具的封装入口真正的逻辑全部在脚本中。快速上手三种最常用调用方式技能文档给出了三个高频用法直接对应脚本 main() 中由 argparse 解析的三个参数。1. 检查最新一次 build.yml 运行默认行为uv run ci/tools/gh/gh_healthcheck.py不带任何参数时脚本以默认值运行workflow_filebuild.yml、run_idNone、detail_levelmedium。run_id为空意味着走get_latest_run()路径——通过gh run list --workflow build.yml --limit 1拉取最近一次运行再对其展开分析。2. 检查指定 runuv run ci/tools/gh/gh_healthcheck.py --run-id 18399875461当你要复盘某一次具体的失败时用--run-id锁定目标。脚本会调用gh run view run-id获取该次运行的标题、分支、触发事件push / pull_request / workflow_dispatch 等、状态与结论。run ID 可以直接从 GitHub Actions 页面 URL 的actions/runs/数字部分获得。3. 高详情模式uv run ci/tools/gh/gh_healthcheck.py --detail high--detail控制分析深度取值low | medium | high默认medium。high 模式会额外打印每个失败 job 的详细错误日志区块详见下文三级详情模式。参数速查表参数取值默认值作用--workflow工作流文件名build.yml指定要分析的工作流--run-idGitHub Actions run ID最新一次运行指定要分析的具体运行--detaillow/medium/highmedium分析深度速度与信息量权衡对应源码中的 argparse 定义见 gh_healthcheck.py。另需注意脚本依赖ghCLIGitHub 官方命令行工具并要求当前处于已认证的 git 仓库中——仓库名通过gh repo view --json nameWithOwner动态获取失败时回退为FastLED/FastLED。三级详情模式速度与深度的取舍详情级别是 gh-healthcheck 的核心设计技能文档中的说明可以归纳为级别行为特点low仅输出摘要不抓取任何 job 日志⚡ 最快适合快速扫一眼整体状态medium抓取失败 job 日志并按类别聚合错误⚖️ 默认档均衡high输出完整错误详情及上下文 最慢适合深挖根因对应实现位于 run_healthcheck()low模式下失败 job 的errors列表为空报告只呈现运行信息与 job 汇总不产生任何网络日志请求medium/high模式下对每个失败 job 调用get_job_logs(job_id)抓取日志经analyze_logs()过滤出错误行medium只保留聚合后的根因类别与受影响项high则额外展开每个 job 前若干条错误的原始内容。选择建议日常 PR 巡检用默认medium只想确认有没有挂、挂几个用low秒回某次失败需要逐条看编译错误原文时再上high。脚本自身的 epilog 帮助文本也给出了这四种典型组合。读懂健康报告从 Run Information 到 Recommendations健康检查的产出是 print_health_report() 打印的结构化文本报告。技能文档与 ci/tools/gh/README.md 给出了完整输出样例报告分五个区块① Run Information运行元信息 Run Information: Run ID: 18399875461 Title: feat(compile_perf): add support for tracking header include tree Branch: master Event: push Status: completed Conclusion: failure来源于gh run view的 JSON 字段displayTitle、headBranch、event、status、conclusion用于快速定位这次运行是哪个提交、什么事件触发的。② Job Summary失败面评估 Job Summary: Total Jobs: 17 ✅ Passed: 13 ❌ Failed: 4这是判断失败性质的第一手依据如果 17 个 job 只有 1 个失败大概率是平台/环境特有问题如果全部失败则可能指向构建系统级故障。脚本在 Recommendations 区块中正是依据failed_jobs 1与failed_jobs total_jobs给出对应提示见 print_health_report。③ Failed Jobs 清单列出每个失败 job 的名称与结论failure/cancelled/timed_out例如build_esp32dev_idf33 / build (failure)。失败判定逻辑见 run_healthcheck()只要 job 结论落在failure、cancelled、timed_out三者之一即视为失败。④ Root Cause Analysis根因聚合这是本工具的核心价值所在。报告按类别聚合所有失败 job 的错误按出现次数降序排列 Root Cause Analysis: 1. Missing Header (15 occurrences) Description: Missing include file Suggestion: Check if header exists for this platform/version Affected: - soc/soc_caps.h - esp_system.h每一项都包含类别名、出现次数、类别描述、修复建议以及在 medium/high 模式下最多展示 5 个受影响的具体目标如缺失的头文件名、未定义的符号名。聚合逻辑由group_errors_by_category()与extract_root_causes()完成详见下节。⑤ Recommendations条件化建议根据聚合结果自动生成的行动建议例如检测到 Missing Header 时建议使用条件包含#if __has_include(...)检测到 Platform Resolution 失败时提示平台可能已弃用考虑升级或移除单个 job 失败提示问题可能仅限特定平台全部失败则提示可能是根本性构建系统问题。退出码可供脚本化使用退出码含义0工作流健康所有 job 通过1检测到失败见 run_healthcheck() 的返回值与 main() 的sys.exit(exit_code)。这意味着该工具可以嵌入 CI 巡检、Agent 自动判定等流程中通过退出码直接驱动后续动作。源码级原理错误分类与根因提取是怎么实现的gh_healthcheck.py的健康检查不是简单把日志里的 error 行罗列出来而是通过模式匹配 → 分类 → 聚合 → 细节提取四步流水线得到结构化根因。预定义的错误模式表脚本在 ERROR_PATTERNS 中定义了ErrorPattern数据类pattern/category/description/suggestion四个字段内置 5 类模式正则模式节选分类类别描述建议fatal error: ([^:]): No such file or directoryMissing Header缺失包含文件检查该平台/版本下头文件是否存在undefined reference to ...Linker Error未定义符号缺少实现或库依赖error: ... was not declaredUndeclared Identifier符号不在作用域内检查 include 与命名空间使用fbuild|build error ... platform ... not found/failed to resolvePlatform Resolutionfbuild 无法解析平台平台可能已弃用或不可用compilation terminatedCompilation Fatal编译被终止修复前置错误这份模式表高度贴合 FastLED 的实际构建生态Missing Header对应跨平台头文件缺失如不同 ESP-IDF 版本间的soc/soc_caps.h、esp_system.hPlatform Resolution对应 fbuild 平台解析失败Linker Error对应链接期符号缺失。日志分析与上下文提取analyze_logs() 逐行扫描日志凡行内出现error或fatal大小写不敏感即视为错误行用ERROR_PATTERNS逐个匹配确定类别匹配不到则归为Generic Error同时截取该行前后各 3 行作为上下文便于人工复核。根因细节提取extract_root_causes() 对聚合结果做二次提取对Missing Header类错误用正则抠出具体的缺失文件名对Linker Error类错误抠出未定义的符号名收集为去重集合后写入根因对象的details字段——这正是报告里Affected:列表的数据来源让缺了什么一目了然。日志获取策略只取最后 1000 行get_job_logs() 通过gh api /repos/{repo}/actions/jobs/{job_id}/logs抓取单个 job 日志并只保留末尾 1000 行——因为编译失败的错误通常集中在日志尾部截断能显著降低网络与内存开销。抓取超时30 秒或失败时静默返回空列表不影响整体报告输出这也解释了为什么个别失败 job 可能没有错误细节。完整调用链一次健康检查背后发生了什么从命令到报告HealthChecker的完整流程如下uv run ci/tools/gh/gh_healthcheck.py [--workflow build.yml] [--run-id N] [--detail medium] │ ├─ _get_repo() → gh repo view --json nameWithOwner 获取 owner/repo ├─ get_latest_run() → gh run list --workflow build.yml --limit 1 │ run_id 为空时定位最新一次运行取 databaseId ├─ get_run_info() → gh run view run-id --json displayTitle,status,... │ 运行元信息 jobs 列表 ├─ 遍历 jobs筛选 conclusion ∈ {failure, cancelled, timed_out} │ └─ (medium/high) get_job_logs() → gh api .../actions/jobs/id/logs │ └─ analyze_logs() → 错误行 类别 ±3 行上下文 ├─ group_errors_by_category() → 按类别分组 ├─ extract_root_causes() → 类别 × 次数 × 描述 × 建议 × 细节 └─ print_health_report() → 五区块报告 条件化建议 └─ 返回退出码 0健康/ 1有失败整个流程对ghCLI 的依赖点有三个gh repo view识别仓库、gh run list/gh run view获取运行与 job 元数据、gh api抓取 job 日志。所有外部命令通过仓库统一的RunningProcess封装执行并接入了ci.util.global_interrupt_handler的键盘中断处理保证 Ctrl-C 时优雅退出见 gh_healthcheck.py 与 ci/tools/gh/init.py 的导出。工具矩阵gh-healthcheck 与 gh-debug、workflow_scanner 如何分工技能文档专门用一节说明与/gh-debug的差异。结合 ci/tools/gh/README.mdFastLED 的 GitHub Actions 排查工具链其实是三个工具协同工具定位速度详情粒度gh_healthcheck.py/gh-healthcheck整个 workflow 的概览与根因模式分析⚡ 快摘要 聚合根因 建议workflow_scanner.py流式输出 workflow 内所有错误块并发抓日志、串行输出防缓冲溢出⚖️ 中每个错误 ±20 行上下文gh_debug.py/gh-debug见 .claude/skills/gh-debug/SKILL.md单次运行的深度下钻优先下载 build-summary 产物加速 慢完整日志 关键错误分类选型逻辑很清晰先跑gh-healthcheck拿全局结论——挂没挂、挂几个、集中在哪类根因如果需要对某个 workflow 的所有失败逐个过一遍错误上下文用workflow_scanner若健康检查定位到某个具体 run 值得深挖再用/gh-debuguv run ci/tools/gh_debug.py run-id拉全量日志逐条分析。环境要求与常见问题排查前置条件ghCLI 已安装并完成认证gh auth status可验证当前目录是一个 git 仓库用于gh repo view获取仓库名失败时回退FastLED/FastLED仓库可通过uv run执行ci/tools/gh/下的 Python 脚本FastLED 仓库的pyproject.toml已配置相应依赖。常见问题与对策现象原因与对策No workflow runs found检查--workflow文件名是否正确默认build.yml确认该 workflow 至少运行过一次确认gh已认证Error getting repo info不在 git 仓库中、gh未安装或未登录用gh auth login认证日志抓取超时大日志文件超 30 秒阈值可改用workflow_scanner.py或调低分析范围job 失败但无错误细节可能是low详情模式不抓日志或日志抓取失败被静默跳过找不到对应 job 的错误错误可能在日志中部被截断脚本只保留末 1000 行可用gh_debug.py下钻小结把 CI 排查从翻日志变成看报告gh-healthcheck是 FastLED 仓库 CI 运维体系里第一道闸门式的工具它以一次命令调用换取对整条 workflow 的健康画像——运行元信息、失败面统计、按类别聚合的根因缺失头文件、链接错误、平台解析失败等和可执行修复建议并通过退出码与三级详情模式兼顾了快查与深挖两种诉求。其设计思路模式驱动的错误分类、日志尾部截断、细节二次提取、条件化建议也值得在自建 CI 巡检工具时借鉴。结合workflow_scanner与gh_debug即可组成覆盖概览 → 扫描 → 深挖三个粒度的完整排查链路相关文档与实现均可在 ci/tools/gh/README.md 与 ci/tools/gh/gh_healthcheck.py 中继续查阅。赞分享嵌入式物联网硬件开发驱动开发【免费下载链接】FastLEDThe FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r Wed like to use github issues just for tracking library bugs / enhancements.项目地址https://gitcode.com/gh_mirrors/fa/FastLED点击查看免费下载相关推荐推荐健康检查库——healthcheck推荐健康检查库——healthcheck 项目介绍 healthcheck 是一个专为 Kubernetes 设计的 Go 语言库用于在你的应用程序中实现SkyWalking OAP 健康检查指南HTTP /healthcheck 端点与模块健康探测原理SkyWalking OAP 健康检查指南HTTP /healthcheck 端点与模块健康探测原理 导读 本文围绕 SkyWalking OAP 后端暴露的可观测性APM链路追踪指标监控日志分析微服务推荐健康检查库——healthcheck为您的Kubernetes应用护航推荐健康检查库——healthcheck为您的Kubernetes应用护航 在现代云原生架构中确保应用程序的稳定性和可访问性是至关重要的。今天我们将探索一上一篇GI-cutscenes轻松提取和转换《原神》过场动画的终极指南下一篇推荐文章探索高效大模型新境界 —— BitNet 开源项目解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FastLED 仓库 GitHub Actions 工作流健康检查指南：gh-healthcheck 的根因分析与三级详情模式
嵌入式物联网硬件开发驱动开发【免费下载链接】FastLEDThe FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r Wed like to use github issues just for tracking library bugs / enhancements.项目地址https://gitcode.com/gh_mirrors/fa/FastLED点击查看免费下载本文以 FastLED 仓库内置的 gh-healthcheck 技能定义 及其背后实现 ci/tools/gh/gh_healthcheck.py 为主线讲解如何对 GitHub Actions 工作流做快速健康检查一次命令拿到整体 CI 状态、失败 job 清单、按类别聚合的根因分析Missing Header、Linker Error、Platform Resolution 等以及可落地的修复建议。读完本文你将掌握uv run ci/tools/gh/gh_healthcheck.py的完整用法、三个详情级别low / medium / high的取舍以及读懂健康报告与退出码含义的能力并理解其底层的日志抓取与错误分类实现原理。gh-healthcheck 是什么面向 fork 场景的 CI 快速体检FastLED 是一个多平台Arduino、ESP32、RP2040、STM32 等彩色 LED 动画库其 build.yml 汇聚了大量平台构建 job一次 push 或 PR 可能触发数十个并行构建。当 CI 变红时逐个 job 翻日志效率很低且多人协作的 fork 场景下经常需要快速判断这次失败是普遍性的还是某个平台特有的。gh-healthcheck正是为此设计的 Claude Code Skill定义于 .claude/skills/gh-healthcheck/SKILL.md声明context: fork说明它主要服务于 fork 分支上的 CI 状态快速概览与模式分析。它的核心能力一句话概括Analyze GitHub Actions workflow health and provide a comprehensive diagnostic report——获取工作流运行数据聚合所有失败 job 的错误按根因类别分组输出诊断报告与修复建议。技能内部的实际执行只有一条命令uv run ci/tools/gh/gh_healthcheck.py $ARGUMENTS其中$ARGUMENTS是调用时传入的参数原样透传。也就是说这个 Skill 是对 ci/tools/gh/gh_healthcheck.py 这一 Python 工具的封装入口真正的逻辑全部在脚本中。快速上手三种最常用调用方式技能文档给出了三个高频用法直接对应脚本 main() 中由 argparse 解析的三个参数。1. 检查最新一次 build.yml 运行默认行为uv run ci/tools/gh/gh_healthcheck.py不带任何参数时脚本以默认值运行workflow_filebuild.yml、run_idNone、detail_levelmedium。run_id为空意味着走get_latest_run()路径——通过gh run list --workflow build.yml --limit 1拉取最近一次运行再对其展开分析。2. 检查指定 runuv run ci/tools/gh/gh_healthcheck.py --run-id 18399875461当你要复盘某一次具体的失败时用--run-id锁定目标。脚本会调用gh run view run-id获取该次运行的标题、分支、触发事件push / pull_request / workflow_dispatch 等、状态与结论。run ID 可以直接从 GitHub Actions 页面 URL 的actions/runs/数字部分获得。3. 高详情模式uv run ci/tools/gh/gh_healthcheck.py --detail high--detail控制分析深度取值low | medium | high默认medium。high 模式会额外打印每个失败 job 的详细错误日志区块详见下文三级详情模式。参数速查表参数取值默认值作用--workflow工作流文件名build.yml指定要分析的工作流--run-idGitHub Actions run ID最新一次运行指定要分析的具体运行--detaillow/medium/highmedium分析深度速度与信息量权衡对应源码中的 argparse 定义见 gh_healthcheck.py。另需注意脚本依赖ghCLIGitHub 官方命令行工具并要求当前处于已认证的 git 仓库中——仓库名通过gh repo view --json nameWithOwner动态获取失败时回退为FastLED/FastLED。三级详情模式速度与深度的取舍详情级别是 gh-healthcheck 的核心设计技能文档中的说明可以归纳为级别行为特点low仅输出摘要不抓取任何 job 日志⚡ 最快适合快速扫一眼整体状态medium抓取失败 job 日志并按类别聚合错误⚖️ 默认档均衡high输出完整错误详情及上下文 最慢适合深挖根因对应实现位于 run_healthcheck()low模式下失败 job 的errors列表为空报告只呈现运行信息与 job 汇总不产生任何网络日志请求medium/high模式下对每个失败 job 调用get_job_logs(job_id)抓取日志经analyze_logs()过滤出错误行medium只保留聚合后的根因类别与受影响项high则额外展开每个 job 前若干条错误的原始内容。选择建议日常 PR 巡检用默认medium只想确认有没有挂、挂几个用low秒回某次失败需要逐条看编译错误原文时再上high。脚本自身的 epilog 帮助文本也给出了这四种典型组合。读懂健康报告从 Run Information 到 Recommendations健康检查的产出是 print_health_report() 打印的结构化文本报告。技能文档与 ci/tools/gh/README.md 给出了完整输出样例报告分五个区块① Run Information运行元信息 Run Information: Run ID: 18399875461 Title: feat(compile_perf): add support for tracking header include tree Branch: master Event: push Status: completed Conclusion: failure来源于gh run view的 JSON 字段displayTitle、headBranch、event、status、conclusion用于快速定位这次运行是哪个提交、什么事件触发的。② Job Summary失败面评估 Job Summary: Total Jobs: 17 ✅ Passed: 13 ❌ Failed: 4这是判断失败性质的第一手依据如果 17 个 job 只有 1 个失败大概率是平台/环境特有问题如果全部失败则可能指向构建系统级故障。脚本在 Recommendations 区块中正是依据failed_jobs 1与failed_jobs total_jobs给出对应提示见 print_health_report。③ Failed Jobs 清单列出每个失败 job 的名称与结论failure/cancelled/timed_out例如build_esp32dev_idf33 / build (failure)。失败判定逻辑见 run_healthcheck()只要 job 结论落在failure、cancelled、timed_out三者之一即视为失败。④ Root Cause Analysis根因聚合这是本工具的核心价值所在。报告按类别聚合所有失败 job 的错误按出现次数降序排列 Root Cause Analysis: 1. Missing Header (15 occurrences) Description: Missing include file Suggestion: Check if header exists for this platform/version Affected: - soc/soc_caps.h - esp_system.h每一项都包含类别名、出现次数、类别描述、修复建议以及在 medium/high 模式下最多展示 5 个受影响的具体目标如缺失的头文件名、未定义的符号名。聚合逻辑由group_errors_by_category()与extract_root_causes()完成详见下节。⑤ Recommendations条件化建议根据聚合结果自动生成的行动建议例如检测到 Missing Header 时建议使用条件包含#if __has_include(...)检测到 Platform Resolution 失败时提示平台可能已弃用考虑升级或移除单个 job 失败提示问题可能仅限特定平台全部失败则提示可能是根本性构建系统问题。退出码可供脚本化使用退出码含义0工作流健康所有 job 通过1检测到失败见 run_healthcheck() 的返回值与 main() 的sys.exit(exit_code)。这意味着该工具可以嵌入 CI 巡检、Agent 自动判定等流程中通过退出码直接驱动后续动作。源码级原理错误分类与根因提取是怎么实现的gh_healthcheck.py的健康检查不是简单把日志里的 error 行罗列出来而是通过模式匹配 → 分类 → 聚合 → 细节提取四步流水线得到结构化根因。预定义的错误模式表脚本在 ERROR_PATTERNS 中定义了ErrorPattern数据类pattern/category/description/suggestion四个字段内置 5 类模式正则模式节选分类类别描述建议fatal error: ([^:]): No such file or directoryMissing Header缺失包含文件检查该平台/版本下头文件是否存在undefined reference to ...Linker Error未定义符号缺少实现或库依赖error: ... was not declaredUndeclared Identifier符号不在作用域内检查 include 与命名空间使用fbuild|build error ... platform ... not found/failed to resolvePlatform Resolutionfbuild 无法解析平台平台可能已弃用或不可用compilation terminatedCompilation Fatal编译被终止修复前置错误这份模式表高度贴合 FastLED 的实际构建生态Missing Header对应跨平台头文件缺失如不同 ESP-IDF 版本间的soc/soc_caps.h、esp_system.hPlatform Resolution对应 fbuild 平台解析失败Linker Error对应链接期符号缺失。日志分析与上下文提取analyze_logs() 逐行扫描日志凡行内出现error或fatal大小写不敏感即视为错误行用ERROR_PATTERNS逐个匹配确定类别匹配不到则归为Generic Error同时截取该行前后各 3 行作为上下文便于人工复核。根因细节提取extract_root_causes() 对聚合结果做二次提取对Missing Header类错误用正则抠出具体的缺失文件名对Linker Error类错误抠出未定义的符号名收集为去重集合后写入根因对象的details字段——这正是报告里Affected:列表的数据来源让缺了什么一目了然。日志获取策略只取最后 1000 行get_job_logs() 通过gh api /repos/{repo}/actions/jobs/{job_id}/logs抓取单个 job 日志并只保留末尾 1000 行——因为编译失败的错误通常集中在日志尾部截断能显著降低网络与内存开销。抓取超时30 秒或失败时静默返回空列表不影响整体报告输出这也解释了为什么个别失败 job 可能没有错误细节。完整调用链一次健康检查背后发生了什么从命令到报告HealthChecker的完整流程如下uv run ci/tools/gh/gh_healthcheck.py [--workflow build.yml] [--run-id N] [--detail medium] │ ├─ _get_repo() → gh repo view --json nameWithOwner 获取 owner/repo ├─ get_latest_run() → gh run list --workflow build.yml --limit 1 │ run_id 为空时定位最新一次运行取 databaseId ├─ get_run_info() → gh run view run-id --json displayTitle,status,... │ 运行元信息 jobs 列表 ├─ 遍历 jobs筛选 conclusion ∈ {failure, cancelled, timed_out} │ └─ (medium/high) get_job_logs() → gh api .../actions/jobs/id/logs │ └─ analyze_logs() → 错误行 类别 ±3 行上下文 ├─ group_errors_by_category() → 按类别分组 ├─ extract_root_causes() → 类别 × 次数 × 描述 × 建议 × 细节 └─ print_health_report() → 五区块报告 条件化建议 └─ 返回退出码 0健康/ 1有失败整个流程对ghCLI 的依赖点有三个gh repo view识别仓库、gh run list/gh run view获取运行与 job 元数据、gh api抓取 job 日志。所有外部命令通过仓库统一的RunningProcess封装执行并接入了ci.util.global_interrupt_handler的键盘中断处理保证 Ctrl-C 时优雅退出见 gh_healthcheck.py 与 ci/tools/gh/init.py 的导出。工具矩阵gh-healthcheck 与 gh-debug、workflow_scanner 如何分工技能文档专门用一节说明与/gh-debug的差异。结合 ci/tools/gh/README.mdFastLED 的 GitHub Actions 排查工具链其实是三个工具协同工具定位速度详情粒度gh_healthcheck.py/gh-healthcheck整个 workflow 的概览与根因模式分析⚡ 快摘要 聚合根因 建议workflow_scanner.py流式输出 workflow 内所有错误块并发抓日志、串行输出防缓冲溢出⚖️ 中每个错误 ±20 行上下文gh_debug.py/gh-debug见 .claude/skills/gh-debug/SKILL.md单次运行的深度下钻优先下载 build-summary 产物加速 慢完整日志 关键错误分类选型逻辑很清晰先跑gh-healthcheck拿全局结论——挂没挂、挂几个、集中在哪类根因如果需要对某个 workflow 的所有失败逐个过一遍错误上下文用workflow_scanner若健康检查定位到某个具体 run 值得深挖再用/gh-debuguv run ci/tools/gh_debug.py run-id拉全量日志逐条分析。环境要求与常见问题排查前置条件ghCLI 已安装并完成认证gh auth status可验证当前目录是一个 git 仓库用于gh repo view获取仓库名失败时回退FastLED/FastLED仓库可通过uv run执行ci/tools/gh/下的 Python 脚本FastLED 仓库的pyproject.toml已配置相应依赖。常见问题与对策现象原因与对策No workflow runs found检查--workflow文件名是否正确默认build.yml确认该 workflow 至少运行过一次确认gh已认证Error getting repo info不在 git 仓库中、gh未安装或未登录用gh auth login认证日志抓取超时大日志文件超 30 秒阈值可改用workflow_scanner.py或调低分析范围job 失败但无错误细节可能是low详情模式不抓日志或日志抓取失败被静默跳过找不到对应 job 的错误错误可能在日志中部被截断脚本只保留末 1000 行可用gh_debug.py下钻小结把 CI 排查从翻日志变成看报告gh-healthcheck是 FastLED 仓库 CI 运维体系里第一道闸门式的工具它以一次命令调用换取对整条 workflow 的健康画像——运行元信息、失败面统计、按类别聚合的根因缺失头文件、链接错误、平台解析失败等和可执行修复建议并通过退出码与三级详情模式兼顾了快查与深挖两种诉求。其设计思路模式驱动的错误分类、日志尾部截断、细节二次提取、条件化建议也值得在自建 CI 巡检工具时借鉴。结合workflow_scanner与gh_debug即可组成覆盖概览 → 扫描 → 深挖三个粒度的完整排查链路相关文档与实现均可在 ci/tools/gh/README.md 与 ci/tools/gh/gh_healthcheck.py 中继续查阅。赞分享嵌入式物联网硬件开发驱动开发【免费下载链接】FastLEDThe FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r Wed like to use github issues just for tracking library bugs / enhancements.项目地址https://gitcode.com/gh_mirrors/fa/FastLED点击查看免费下载相关推荐推荐健康检查库——healthcheck推荐健康检查库——healthcheck 项目介绍 healthcheck 是一个专为 Kubernetes 设计的 Go 语言库用于在你的应用程序中实现SkyWalking OAP 健康检查指南HTTP /healthcheck 端点与模块健康探测原理SkyWalking OAP 健康检查指南HTTP /healthcheck 端点与模块健康探测原理 导读 本文围绕 SkyWalking OAP 后端暴露的可观测性APM链路追踪指标监控日志分析微服务推荐健康检查库——healthcheck为您的Kubernetes应用护航推荐健康检查库——healthcheck为您的Kubernetes应用护航 在现代云原生架构中确保应用程序的稳定性和可访问性是至关重要的。今天我们将探索一上一篇GI-cutscenes轻松提取和转换《原神》过场动画的终极指南下一篇推荐文章探索高效大模型新境界 —— BitNet 开源项目解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考