GitHub Actions 怎么查看公开仓库失败步骤：从运行列表到日志定位

遇到 GitHub Actions 失败时，最有用的不是先重跑，而是先把失败定位到具体的工作流、Job 和 Step。下面用 GitHub 官方公开仓库 github/docs 的一次失败运行做示范，从仓库的 Actions 入口一路打开到失败日志，最后确认错误发生在哪个步骤。

先确定要看的运行记录

这次示例使用 github/docs 的 Lint code 运行记录。它是公开仓库的真实 Actions 页面，运行编号是 12027，结论为失败。你也可以换成自己有读取权限的仓库，但按钮名称和判断顺序保持一致。

按编号路径打开失败运行

第 1 步：进入仓库的 Actions 页面

打开 GitHub 仓库主页，点击仓库名称下方的 Actions。页面左侧会出现工作流列表，中间区域显示最近运行记录。

可见成功状态：地址进入仓库的 Actions 页面，左侧能看到工作流名称，说明入口选择正确。若页面要求登录，先登录有读取权限的 GitHub 账号；公开仓库的具体运行信息也可能受账号状态影响。

第 2 步：选择工作流并打开运行摘要

在左侧点击目标工作流，例如 Lint code；在右侧运行列表中点击失败记录。示例运行标题会显示 Lint code #12027，进入后能看到本次运行的 Summary 页面。

可见成功状态：页面标题和运行编号与目标记录一致，并出现红色失败标记。此时先记下失败发生的分支、提交和运行时间，避免误看另一条相邻记录。

第 3 步：展开失败 Job 和具体 Step

在运行摘要的 Jobs 区域点击带红色失败标记的 Job，再在步骤列表中点击带红色图标的 Step。页面会展开该步骤的日志输出，按时间顺序查看最后一个明确的错误行。

可见成功状态：具体 Step 已展开并出现日志面板；官方示例图展示的是成功运行，但失败运行使用同一套步骤展开和日志查看界面，判断依据仍以红色失败标记和错误日志为准。

日志里应该核对哪些信息

这里别急着把日志最后一行当作根因。有些步骤在真正错误之后只是在做清理。更稳妥的做法是从红色失败 Step 的末尾向上读，找到第一个带有错误上下文的输出，再回到摘要确认 Job 和提交没有看错。

常见问题

为什么看不到 Actions 运行详情？

先检查当前账号是否登录，以及账号对仓库是否有读取权限。官方文档明确要求具备仓库读取权限；页面若仍不可见，应让仓库管理员确认访问范围。

红色 Job 一定代表代码测试失败吗？

不一定。失败可能来自依赖安装、权限、环境准备或测试步骤。必须展开具体 Step，再依据日志中的错误上下文判断。

什么时候适合点击 Re-run jobs？

只有在日志显示临时网络、Runner 或依赖服务波动，并且代码和提交本身没有变化时才考虑重跑。确定是代码或配置错误时，应先修复再运行。

最后确认排查结果

完成一次查看后，至少留下工作流名称、运行编号、分支或提交、失败 Job、失败 Step 和第一处明确错误。这样下一位处理者可以直接从同一条运行记录复核，不必重新翻整页历史。