Renovate 仓库缓存Repository Cache数据结构解析与在线解码实战【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 在每次运行时会把仓库级扫描结果缓存到本地或 S3避免重复提取依赖、重复调用平台 API。缓存文件并非明文 JSON而是经过 Brotli 压缩、Base64 编码并附带哈希与指纹的「密封」记录。本文基于lib/util/cache/repository的源码实现逐字段拆解缓存记录的结构fingerprint / hash / payload / revision / repository并给出使用官方在线 cache decoder 解码缓存数据的完整实操步骤帮助你排查缓存损坏、指纹不匹配等疑难问题。一、背景为什么 Renovate 需要仓库级缓存Renovate 对一个仓库的完整处理流程包括读取配置 → 提取依赖extract→ 更新分支update→ 创建 PR。其中依赖提取与平台查询GitHub / GitLab / Gitea 等开销巨大因此 Renovate 引入「repository cache」机制把上一次运行得到的中间结果持久化下次运行时直接复用。从源码结构看缓存的数据形态由 lib/util/cache/repository/types.ts 中的RepoCacheData接口定义主要包含字段含义branches各更新分支的缓存BranchCache含升级详情、PR 缓存、冲突状态等scan各基础分支的扫描结果BaseBranchCache含 packageFiles 提取结果与指纹init仓库初始化配置httpCache/httpCacheHead平台 HTTP 请求缓存onboardingBranchCache/reconfigureBranchCacheonboarding 与 reconfigure 分支状态platform各平台内部缓存如 GitHub 的 PR 列表、GraphQL 分页、issues这些数据经序列化、压缩、加密可选后以统一格式写入持久层。二、缓存记录的五字段结构无论存储在后端是本地文件还是 S3写入的每条缓存记录都遵循同一个 JSON 结构该结构由 lib/util/cache/repository/schema.ts 中的RepoCacheRecord严格校验{ fingerprint: 0123456789abcdef, hash: 756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45, payload: Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB, repository: some/repo, revision: 13 }1.revision缓存结构版本号revision用于标识缓存结构的版本。当前版本固定为13定义在 lib/util/cache/repository/common.ts// Increment this whenever there could be incompatibilities between old and new cache structure export const CACHE_REVISION 13;每当我们修改缓存数据结构导致新旧格式不兼容时该版本号都会递增。schema 中用z.number().refine((v) v 13)强制校验只要revision不等于 13整条记录就会判定为无效并被丢弃从而避免用旧结构解析新数据。2.repository仓库标识记录所属的仓库例如some/repo。读取时它用于定位缓存文件路径见后文「存储后端」schema 要求其为长度 ≥ 1 的字符串。3.fingerprint仓库指纹防串库fingerprint是仓库的指纹repo fingerprint由配置与仓库信息计算得出。读取缓存时lib/util/cache/repository/impl/base.ts 的restore()会做严格比对private async restore(oldCache: RepoCacheRecord): Promisevoid { if (oldCache.fingerprint ! this.fingerprint) { logger.debug(Repository cache fingerprint is invalid); return; } const jsonStr await decompressFromBase64(oldCache.payload); this.data RepoCacheBase.parseData(jsonStr); this.oldHash oldCache.hash; }指纹不匹配时直接丢弃旧缓存并输出Repository cache fingerprint is invalid的 debug 日志。这保证了一个仓库的缓存绝不会被另一个仓库或配置发生重大变化后的同一仓库的旧缓存污染。实际排查时若发现缓存总是失效重建可优先检查 fingerprint 相关日志。4.payloadBrotli 压缩 Base64 编码的数据体payload是缓存数据的真正载体。它并不是明文而是将RepoCacheData通过safeStringify序列化为 JSON 字符串使用 Brotli 算法文本模式、质量等级 8压缩为二进制 Buffer将压缩结果编码为 Base64 字符串。对应实现位于 lib/util/compress.tsexport async function compressToBase64(input: string): Promisestring { const buf await compressToBuffer(input); return buf.toString(base64); }之所以采用 Brotli 而非 gzip是因为 Brotli 对 JSON 文本的压缩率更高能显著缩小缓存体积。这也是payload看起来是一串「乱码」而非可读 JSON 的原因——它是压缩后的密文需要通过 decoder 或手动解压才能还原。5.hash内容哈希用于判断是否需要写回hash是序列化后 JSON 字符串的哈希值见 lib/util/cache/repository/impl/base.ts。save()时流程为async save(): Promisevoid { cleanupHttpCache(this.data); const jsonStr safeStringify(this.data); const hashedJsonStr hash(jsonStr); if (hashedJsonStr this.oldHash) { return; // 内容没有变化跳过写盘 } // ...压缩 payload 并写入 }即只有缓存内容真正发生变化时才会重新压缩并写盘未变化时直接跳过节省 I/O。同时isModified()也依赖哈希比对来判断本次运行是否修改过缓存。三、存储后端local / s3 / nullRepoCacheRecord最终由哪个后端持久化取决于repositoryCache配置。工厂类 lib/util/cache/repository/impl/cache-factory.ts 根据cacheType的前缀分发const type cacheType.split(://)[0].trim().toLowerCase(); switch (type) { case local: return new RepoCacheLocal(repository, repoFingerprint); case s3: return new RepoCacheS3(repository, repoFingerprint, cacheType); default: logger.warn({ cacheType }, Repository cache type not supported using type local instead); return new RepoCacheLocal(repository, repoFingerprint); }local写入本地文件。路径规则见 lib/util/cache/repository/common.tsrenovate/repository/platform/repository.json例如renovate/repository/github/some-repo.json。实现见 lib/util/cache/repository/impl/local.ts。s3写入 S3 兼容对象存储对象键为dirplatform/repository/cache.json若同时设置了repositoryCacheForceLocal还会额外写一份本地副本用于调试见 lib/util/cache/repository/impl/s3.ts。null禁用缓存时使用load()/save()均为空操作见 lib/util/cache/repository/impl/null.ts。所有后端都继承自RepoCacheBaselib/util/cache/repository/impl/base.ts只需实现read()与write()两个抽象方法加解密、校验、哈希比对等公共逻辑全部复用。四、实战使用在线 Cache Decoder 解码缓存数据要排查缓存问题例如 payload 无法解析、怀疑缓存被污染最快捷的方式是使用 Renovate 官方提供的在线Cache Decoder工具。4.1 完整记录解码步骤一找到缓存数据。对于 local 后端直接打开缓存文件renovate/repository/platform/repository.json例如renovate/repository/github/some-repo.json其内容即是一段形如下文的 JSON{ fingerprint: 0123456789abcdef, hash: 756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45, payload: Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB, repository: some/repo, revision: 13 }步骤二粘贴到左侧输入框。打开 Cache Decoder 页面把上面整段 JSON 复制粘贴到左侧输入区域。步骤三读取解码结果。点击解码后工具会自动完成 Base64 解码与 Brotli 解压并将还原出的明文 JSON即RepoCacheData包含branches、scan、httpCache等字段复制到你的系统剪贴板直接粘贴即可查看完整内容。4.2 只粘贴 payload 字段可选如果只想查看数据内容、不关心外围字段可以只把payload的值粘贴进去例如Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOABDecoder 同样支持这种简化用法便于在聊天工具或日志中快速分享单条缓存体。4.3 手动解码原理不依赖在线工具如果你希望本地复现解码过程本质就是对payload依次执行两步逆操作Base64 解码Buffer.from(payload, base64)得到压缩字节Brotli 解压使用node:zlib的brotliDecompress还原 UTF-8 文本。对应仓库中的逆操作为 lib/util/compress.tsexport async function decompressFromBase64(input: string): Promisestring { return await decompressFromBuffer(Buffer.from(input, base64)); }解压出的 JSON 再经过RepoCacheBase.parseData()lib/util/cache/repository/impl/base.ts的兼容处理例如把废弃的branchFingerprint迁移为commitFingerprint即得到完整的缓存数据结构。五、缓存失效的常见原因与排查要点结合源码以下情况会导致缓存被判定无效并重建revision 不匹配旧版本缓存revision 13无法通过RepoCacheRecord校验读取时输出Repository cache is invalid警告见 lib/util/cache/repository/impl/base.ts。fingerprint 不匹配仓库指纹变化如配置变更导致指纹重算输出Repository cache fingerprint is invalid旧缓存被安全丢弃。文件缺失或为空read()返回null或空字符串时直接跳过恢复逻辑lib/util/cache/repository/impl/base.ts属于正常冷启动。内容未变化save()时哈希与oldHash相同则跳过写盘这并非失效而是「无需更新」的优化路径。六、小结Renovate 的仓库缓存记录是一个「五字段信封」revision标识格式版本、repository标识仓库、fingerprint防止串库、payload承载 Brotli 压缩后的业务数据、hash用于变更检测。理解这五个字段你就能熟练使用官方 Cache Decoder 还原任何缓存内容也能在遇到「缓存不生效」时快速定位是版本不兼容、指纹变化还是文件缺失。相关核心代码集中在 lib/util/cache/repository 目录可继续深入阅读schema.ts、impl/base.ts与impl/cache-factory.ts加深理解。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Renovate 仓库缓存Repository Cache数据结构解析与在线解码实战【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 在每次运行时会把仓库级扫描结果缓存到本地或 S3避免重复提取依赖、重复调用平台 API。缓存文件并非明文 JSON而是经过 Brotli 压缩、Base64 编码并附带哈希与指纹的「密封」记录。本文基于lib/util/cache/repository的源码实现逐字段拆解缓存记录的结构fingerprint / hash / payload / revision / repository并给出使用官方在线 cache decoder 解码缓存数据的完整实操步骤帮助你排查缓存损坏、指纹不匹配等疑难问题。一、背景为什么 Renovate 需要仓库级缓存Renovate 对一个仓库的完整处理流程包括读取配置 → 提取依赖extract→ 更新分支update→ 创建 PR。其中依赖提取与平台查询GitHub / GitLab / Gitea 等开销巨大因此 Renovate 引入「repository cache」机制把上一次运行得到的中间结果持久化下次运行时直接复用。从源码结构看缓存的数据形态由 lib/util/cache/repository/types.ts 中的RepoCacheData接口定义主要包含字段含义branches各更新分支的缓存BranchCache含升级详情、PR 缓存、冲突状态等scan各基础分支的扫描结果BaseBranchCache含 packageFiles 提取结果与指纹init仓库初始化配置httpCache/httpCacheHead平台 HTTP 请求缓存onboardingBranchCache/reconfigureBranchCacheonboarding 与 reconfigure 分支状态platform各平台内部缓存如 GitHub 的 PR 列表、GraphQL 分页、issues这些数据经序列化、压缩、加密可选后以统一格式写入持久层。二、缓存记录的五字段结构无论存储在后端是本地文件还是 S3写入的每条缓存记录都遵循同一个 JSON 结构该结构由 lib/util/cache/repository/schema.ts 中的RepoCacheRecord严格校验{ fingerprint: 0123456789abcdef, hash: 756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45, payload: Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB, repository: some/repo, revision: 13 }1.revision缓存结构版本号revision用于标识缓存结构的版本。当前版本固定为13定义在 lib/util/cache/repository/common.ts// Increment this whenever there could be incompatibilities between old and new cache structure export const CACHE_REVISION 13;每当我们修改缓存数据结构导致新旧格式不兼容时该版本号都会递增。schema 中用z.number().refine((v) v 13)强制校验只要revision不等于 13整条记录就会判定为无效并被丢弃从而避免用旧结构解析新数据。2.repository仓库标识记录所属的仓库例如some/repo。读取时它用于定位缓存文件路径见后文「存储后端」schema 要求其为长度 ≥ 1 的字符串。3.fingerprint仓库指纹防串库fingerprint是仓库的指纹repo fingerprint由配置与仓库信息计算得出。读取缓存时lib/util/cache/repository/impl/base.ts 的restore()会做严格比对private async restore(oldCache: RepoCacheRecord): Promisevoid { if (oldCache.fingerprint ! this.fingerprint) { logger.debug(Repository cache fingerprint is invalid); return; } const jsonStr await decompressFromBase64(oldCache.payload); this.data RepoCacheBase.parseData(jsonStr); this.oldHash oldCache.hash; }指纹不匹配时直接丢弃旧缓存并输出Repository cache fingerprint is invalid的 debug 日志。这保证了一个仓库的缓存绝不会被另一个仓库或配置发生重大变化后的同一仓库的旧缓存污染。实际排查时若发现缓存总是失效重建可优先检查 fingerprint 相关日志。4.payloadBrotli 压缩 Base64 编码的数据体payload是缓存数据的真正载体。它并不是明文而是将RepoCacheData通过safeStringify序列化为 JSON 字符串使用 Brotli 算法文本模式、质量等级 8压缩为二进制 Buffer将压缩结果编码为 Base64 字符串。对应实现位于 lib/util/compress.tsexport async function compressToBase64(input: string): Promisestring { const buf await compressToBuffer(input); return buf.toString(base64); }之所以采用 Brotli 而非 gzip是因为 Brotli 对 JSON 文本的压缩率更高能显著缩小缓存体积。这也是payload看起来是一串「乱码」而非可读 JSON 的原因——它是压缩后的密文需要通过 decoder 或手动解压才能还原。5.hash内容哈希用于判断是否需要写回hash是序列化后 JSON 字符串的哈希值见 lib/util/cache/repository/impl/base.ts。save()时流程为async save(): Promisevoid { cleanupHttpCache(this.data); const jsonStr safeStringify(this.data); const hashedJsonStr hash(jsonStr); if (hashedJsonStr this.oldHash) { return; // 内容没有变化跳过写盘 } // ...压缩 payload 并写入 }即只有缓存内容真正发生变化时才会重新压缩并写盘未变化时直接跳过节省 I/O。同时isModified()也依赖哈希比对来判断本次运行是否修改过缓存。三、存储后端local / s3 / nullRepoCacheRecord最终由哪个后端持久化取决于repositoryCache配置。工厂类 lib/util/cache/repository/impl/cache-factory.ts 根据cacheType的前缀分发const type cacheType.split(://)[0].trim().toLowerCase(); switch (type) { case local: return new RepoCacheLocal(repository, repoFingerprint); case s3: return new RepoCacheS3(repository, repoFingerprint, cacheType); default: logger.warn({ cacheType }, Repository cache type not supported using type local instead); return new RepoCacheLocal(repository, repoFingerprint); }local写入本地文件。路径规则见 lib/util/cache/repository/common.tsrenovate/repository/platform/repository.json例如renovate/repository/github/some-repo.json。实现见 lib/util/cache/repository/impl/local.ts。s3写入 S3 兼容对象存储对象键为dirplatform/repository/cache.json若同时设置了repositoryCacheForceLocal还会额外写一份本地副本用于调试见 lib/util/cache/repository/impl/s3.ts。null禁用缓存时使用load()/save()均为空操作见 lib/util/cache/repository/impl/null.ts。所有后端都继承自RepoCacheBaselib/util/cache/repository/impl/base.ts只需实现read()与write()两个抽象方法加解密、校验、哈希比对等公共逻辑全部复用。四、实战使用在线 Cache Decoder 解码缓存数据要排查缓存问题例如 payload 无法解析、怀疑缓存被污染最快捷的方式是使用 Renovate 官方提供的在线Cache Decoder工具。4.1 完整记录解码步骤一找到缓存数据。对于 local 后端直接打开缓存文件renovate/repository/platform/repository.json例如renovate/repository/github/some-repo.json其内容即是一段形如下文的 JSON{ fingerprint: 0123456789abcdef, hash: 756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45, payload: Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB, repository: some/repo, revision: 13 }步骤二粘贴到左侧输入框。打开 Cache Decoder 页面把上面整段 JSON 复制粘贴到左侧输入区域。步骤三读取解码结果。点击解码后工具会自动完成 Base64 解码与 Brotli 解压并将还原出的明文 JSON即RepoCacheData包含branches、scan、httpCache等字段复制到你的系统剪贴板直接粘贴即可查看完整内容。4.2 只粘贴 payload 字段可选如果只想查看数据内容、不关心外围字段可以只把payload的值粘贴进去例如Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOABDecoder 同样支持这种简化用法便于在聊天工具或日志中快速分享单条缓存体。4.3 手动解码原理不依赖在线工具如果你希望本地复现解码过程本质就是对payload依次执行两步逆操作Base64 解码Buffer.from(payload, base64)得到压缩字节Brotli 解压使用node:zlib的brotliDecompress还原 UTF-8 文本。对应仓库中的逆操作为 lib/util/compress.tsexport async function decompressFromBase64(input: string): Promisestring { return await decompressFromBuffer(Buffer.from(input, base64)); }解压出的 JSON 再经过RepoCacheBase.parseData()lib/util/cache/repository/impl/base.ts的兼容处理例如把废弃的branchFingerprint迁移为commitFingerprint即得到完整的缓存数据结构。五、缓存失效的常见原因与排查要点结合源码以下情况会导致缓存被判定无效并重建revision 不匹配旧版本缓存revision 13无法通过RepoCacheRecord校验读取时输出Repository cache is invalid警告见 lib/util/cache/repository/impl/base.ts。fingerprint 不匹配仓库指纹变化如配置变更导致指纹重算输出Repository cache fingerprint is invalid旧缓存被安全丢弃。文件缺失或为空read()返回null或空字符串时直接跳过恢复逻辑lib/util/cache/repository/impl/base.ts属于正常冷启动。内容未变化save()时哈希与oldHash相同则跳过写盘这并非失效而是「无需更新」的优化路径。六、小结Renovate 的仓库缓存记录是一个「五字段信封」revision标识格式版本、repository标识仓库、fingerprint防止串库、payload承载 Brotli 压缩后的业务数据、hash用于变更检测。理解这五个字段你就能熟练使用官方 Cache Decoder 还原任何缓存内容也能在遇到「缓存不生效」时快速定位是版本不兼容、指纹变化还是文件缺失。相关核心代码集中在 lib/util/cache/repository 目录可继续深入阅读schema.ts、impl/base.ts与impl/cache-factory.ts加深理解。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
