现象
.github/workflows/check-links.yml 里 Lychee 的扫描目标是:
args: |
--verbose
--no-progress
--config lychee.toml
'docs/**/*.md'
'docs/**/*.mdx'
'README.md'
但站点发布的文档并不在 docs/,而在 content/docs/(apps/site/source.config.ts 里 dir: '../../content/docs',apps/site/lib/source.ts 里 baseUrl: '/docs')。
实测两棵树的规模:
$ find docs -name '*.md' -o -name '*.mdx' | wc -l
15 # ARCHITECTURE.md、CONSOLE-STREAMLINING-SUMMARY.md、adr/、audits/ …
$ find content/docs -name '*.md' -o -name '*.mdx' | wc -l
183 # 实际发布的站点文档
也就是说:即使有人手动 workflow_dispatch 触发 Lychee,它也从来没有检查过发布出去的那 183 个文档文件。 根目录 docs/ 是内部资料(ADR、审计报告、架构说明),被扫的是它。
为什么现在记为 finding 而不是缺陷
check-links.yml 目前只有 workflow_dispatch(push/pull_request 被注释掉,见 #3213),从不自动运行 —— 属于「未被执行的配置漂移」,今天没有用户会撞到。因此按 finding 归类,不带 pm:queue。
#3213 的裁决是「B 保持定时/手动(可选补 cron)」。修复 #3213 的 PR 有意没有加这条 cron,理由就是本 issue:在扫描范围还指向错误目录时加 cron,只会按时产出一份「检查了内部 ADR、没检查站点文档」的绿色报告,是加噪声不加覆盖,并且会让人误以为已发布文档的外链已被守住。
建议顺序:先修扫描范围,再谈是否加 cron。
建议
- 把 args 的扫描目标改为
content/docs/**/*.md、content/docs/**/*.mdx(是否保留 docs/** 与 README.md 由维护者定;两棵树都扫也合理)。
- 范围修正后,再决定要不要补
schedule cron —— 届时 cron 才有意义。
- 注意 Lychee 是外链检查器(走网络、有 rate limit、天然会 flaky),与
scripts/check-doc-links.mjs 只校验站内 /docs/... 路由是互补关系,不是重复。这也是裁决把 A 放进 PR 门禁、B 留在定时/手动的原因。
相关
现象
.github/workflows/check-links.yml里 Lychee 的扫描目标是:但站点发布的文档并不在
docs/,而在content/docs/(apps/site/source.config.ts里dir: '../../content/docs',apps/site/lib/source.ts里baseUrl: '/docs')。实测两棵树的规模:
也就是说:即使有人手动
workflow_dispatch触发 Lychee,它也从来没有检查过发布出去的那 183 个文档文件。 根目录docs/是内部资料(ADR、审计报告、架构说明),被扫的是它。为什么现在记为 finding 而不是缺陷
check-links.yml目前只有workflow_dispatch(push/pull_request被注释掉,见 #3213),从不自动运行 —— 属于「未被执行的配置漂移」,今天没有用户会撞到。因此按 finding 归类,不带pm:queue。与 #3213 裁决的关系
#3213 的裁决是「B 保持定时/手动(可选补 cron)」。修复 #3213 的 PR 有意没有加这条 cron,理由就是本 issue:在扫描范围还指向错误目录时加 cron,只会按时产出一份「检查了内部 ADR、没检查站点文档」的绿色报告,是加噪声不加覆盖,并且会让人误以为已发布文档的外链已被守住。
建议顺序:先修扫描范围,再谈是否加 cron。
建议
content/docs/**/*.md、content/docs/**/*.mdx(是否保留docs/**与README.md由维护者定;两棵树都扫也合理)。schedulecron —— 届时 cron 才有意义。scripts/check-doc-links.mjs只校验站内/docs/...路由是互补关系,不是重复。这也是裁决把 A 放进 PR 门禁、B 留在定时/手动的原因。相关
pnpm docs:check-links在 main 上就退出 1,但没有任何工作流跑它(两个链接检查器都不拦 PR) #3213 / docs:content/docs/core/enhanced-actions.mdx指向不存在的/docs/components/form#3292 的修复 PR 顺带发现