GitHub公开仓库clone也可能要求认证：检查CI的匿名获取路径

如果构建假设公开仓库随时都能匿名下载，这就成了隐蔽的可用性依赖。GitHub于2026年10月19日宣布，异常流量期间，部分公开仓库的HTTPS clone和fetch可能临时要求认证。这并不代表仓库变为私有。下文的运维检查是作者建议，与公告的产品行为分开理解。

先看清适用范围

这项保护可适用于github.com所有套餐，但不是所有公开仓库的长期认证要求。已认证HTTPS、SSH、push及无关的网页和API流量不受这项措施影响。先读实际错误是否提示需要认证。匿名fetch失败本身不能证明API整体故障或仓库权限变化。

列出安装脚本、Docker构建阶段、子模块和测试数据下载。记录环境、目标仓库、传输方式、是否认证及负责人。已有缓存可能掩盖依赖，应在全新环境检查一个代表性任务。不要向任务不用的路径批量分发凭据。

GitHub建议Actions使用内置GITHUB_TOKEN，其他CI优先使用GitHub App安装令牌，PAT也是选项。工作流令牌受其仓库范围限制，不应假设自动获得其他仓库权限。对照目标和文档设置最小权限。使用CI秘密存储和受支持的认证方式，避免把令牌写入clone URL或调试输出。

保存脱敏错误、时间、传输方式、认证状态和重试结果。认证后仍失败，应分别检查有效期、目标范围、权限和网络。无法认证的环境可按公告在临时保护解除后重试。规定次数和等待上限，并指定升级处理负责人。变更后在新环境验证代码获取及后续构建。

社区对公开代码访问的疑问是调查线索，不是全面关闭的证据。公告没有确定AI流量占比，也没有要求所有remote迁移SSH。从一个受影响的自动化开始，验证访问和撤销流程后再扩大。保存令牌不是完成标准，成功获取并构建才是执行证据。

核查日期：2026年10月20日。先记录一个CI任务的匿名获取路径及凭据负责人。