CodeQL通用包弃用预告：先检查OS与CPU安装路径，再看版本
安全分析工具的版本可能一直在升级，安装文件名却多年未变。如果团队通过自建CI或内部镜像下载CodeQL，现在应同时检查版本和下载对象。
GitHub于2026年9月22日公布了全平台CodeQL包的弃用计划。本文区分公告事实与操作建议，帮助团队把平台专用包迁移变成可审查的变更。
弃用预告不等于当前故障
从CodeQL CLI 2.27.0开始，codeql-bundle.tar.gz与codeql-bundle.tar.zst被标记为弃用，计划于2027年3月中旬移除。建议改用受支持操作系统及架构对应的专用包。
Linux ARM64二进制文件仅在平台专用下载中提供，不包含在通用包中。但这不意味着现有工作流今天都会失败。先确定自己的安装流程是否直接下载了这些文件。
先找到直接安装入口
只搜索工作流YAML，可能漏掉容器镜像、初始化脚本和内部制品库里的安装步骤。请将生成下载URL的位置与实际执行分析的环境关联起来。
可以记录环境、OS、CPU、文件、缓存位置和负责人。这是减少遗漏的运维建议，不是官方强制要求。无需在公开Issue中贴出秘密令牌或内部地址。
不能只凭OS名称选文件
同为Linux，x86-64与ARM64也是不同目标。区分宿主机与容器环境，按发布资源的准确文件名建立映射。对未知组合明确报错，比悄悄使用默认项更容易定位问题。
2.27.0列出了Linux ARM64的CLI与包，但有下载文件不代表支持所有语言和构建组合。目前系统要求将Linux ARM64支持标为beta，因此还应检查适用条件。
不让缓存掩盖迁移失败
即使改了下载文件名，如果缓存仍提供旧可执行文件，就未必测试了新路径。缓存键与镜像路径应体现平台和版本，首次验证应记录实际文件与CLI版本。
使用官方发布文件及其提供的完整性信息。内部保存已验证资源时，也记录原始版本和平台。不同架构共用一个缓存名的情况尤其需要检查。
从能启动到能完成分析
CLI能启动并不能证明分析与以前等效。用代表仓库的同一提交，检查数据库创建、查询执行及结果上传，并比较语言范围与构建模式有无遗漏。
不要把应用重构或查询策略变化混进迁移，否则难以解释差异。单独审查安装路径，遇到异常时按工具版本、包版本与构建日志缩小范围。
从一条可复现路径开始
小团队可以先迁移最重要的一条自建CI。记录成功标准和回退设置，并向镜像与旧镜像负责人分享相同标准，让剩余范围清晰可见。
公开发布与Issue有助于调查兼容性，但别人的仓库结果不能替代自己的验证。本文不宣称社区共识，也不编造迁移成功率。
今天应留下的变更记录
在PR中附上旧文件名、新平台映射、实际环境和代表分析结果。也列出尚未检查的环境，方便审查者理解完成范围。
移除前要做的是修改并验证安装路径，而不是隐藏警告。未来可能公布更精确日期，也应安排负责人复查官方变更记录和系统要求。