Firebase Tools 项目中 Artifact Registry 清理策略的 Dry Run 模式问题分析
在 Firebase Tools 项目的最新版本 14.1.0 中,用户报告了一个关于 Artifact Registry 清理策略的有趣问题。当用户尝试为 Cloud Functions 容器镜像设置清理策略时,系统默认将策略应用为 Dry Run(试运行)模式,而非预期的 Delete artifacts(删除工件)模式。
这个问题最初由用户在三个不同项目中重复观察到,表明这不是偶发性的权限问题。通过深入分析,我们发现问题的根源在于 Artifact Registry API 的默认行为与 Firebase Tools 命令行工具的交互方式。
从技术实现角度来看,当 Firebase CLI 执行清理策略设置时,它会向 Artifact Registry 服务发送 PATCH 请求来更新仓库配置。然而,API 响应中返回的 cleanupPolicyDryRun 字段默认为 true,而 CLI 工具在后续更新操作中未能显式覆盖这个默认值。这导致尽管用户明确选择了删除策略,系统仍然保持试运行模式。
这个问题特别值得注意,因为它不会导致命令执行失败,而是静默地应用了与用户预期不同的配置。对于依赖自动清理来管理存储成本的项目来说,这种差异可能导致存储空间未被及时释放,从而产生不必要的费用。
开发者 Cole Rogers 通过分析调试日志快速定位了问题所在,并提出了修复方案。解决方案的核心是在更新清理策略时,显式设置 cleanupPolicyDryRun 为 false,确保策略按预期在删除模式下运行。
这个问题提醒我们,在与云服务 API 交互时,特别是涉及默认值和可选参数时,需要格外小心。作为最佳实践,工具应该明确设置所有相关参数,而不是依赖服务端的默认行为,这样可以避免类似的意外配置差异。
对于使用 Firebase Tools 管理 Cloud Functions 的用户来说,建议在设置清理策略后,通过 Google Cloud Console 验证策略的实际运行模式,确保配置符合预期。同时,关注工具的未来版本更新,以获取这个问题的官方修复。
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00
GLM-4.7-FlashGLM-4.7-Flash 是一款 30B-A3B MoE 模型。作为 30B 级别中的佼佼者,GLM-4.7-Flash 为追求性能与效率平衡的轻量化部署提供了全新选择。Jinja00
VLOOKVLOOK™ 是优雅好用的 Typora/Markdown 主题包和增强插件。 VLOOK™ is an elegant and practical THEME PACKAGE × ENHANCEMENT PLUGIN for Typora/Markdown.Less00
PaddleOCR-VL-1.5PaddleOCR-VL-1.5 是 PaddleOCR-VL 的新一代进阶模型,在 OmniDocBench v1.5 上实现了 94.5% 的全新 state-of-the-art 准确率。 为了严格评估模型在真实物理畸变下的鲁棒性——包括扫描伪影、倾斜、扭曲、屏幕拍摄和光照变化——我们提出了 Real5-OmniDocBench 基准测试集。实验结果表明,该增强模型在新构建的基准测试集上达到了 SOTA 性能。此外,我们通过整合印章识别和文本检测识别(text spotting)任务扩展了模型的能力,同时保持 0.9B 的超紧凑 VLM 规模,具备高效率特性。Python00
KuiklyUI基于KMP技术的高性能、全平台开发框架,具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意:本仓库为Github仓库镜像,PR或Issue请移步至Github发起,感谢支持!Kotlin07
compass-metrics-modelMetrics model project for the OSS CompassPython00