Docker Build Push Action 中关于未标记镜像问题的分析与解决

问题背景

在使用 Docker Build Push Action 进行镜像构建和推送时，用户发现 GitHub 容器注册表中出现了大量未标记(untagged)的镜像。这些镜像从历史记录看与现有标记镜像几乎完全相同，这引发了用户对构建流程是否正确的疑问。

现象描述

用户配置了标准的构建推送流程，包括：

1. 使用 metadata-action 提取镜像元数据
2. 使用 build-push-action 构建并推送镜像
3. 指定了单一平台(linux/amd64)
4. 禁用了 provenance 功能

尽管配置看似合理，但在某些情况下仍会产生未标记镜像。这些镜像与已标记镜像内容几乎相同，造成了存储空间的浪费和管理上的困扰。

技术分析

经过深入分析，发现这种现象与容器注册表的工作机制有关：

1. 镜像推送机制：当推送新版本的标记镜像时，旧版本的标记会被移除，但镜像本身(通过SHA256标识)仍保留在注册表中，成为"未标记"状态。

2. GitHub容器注册表特性：与其他注册表(如公共容器仓库)不同，GitHub会明确显示这些未标记的镜像，而其他平台可能只是隐藏它们。

3. 多平台构建影响：即使用户只构建单一平台镜像，每次构建产生的新镜像SHA也会导致旧版本变为未标记状态。

解决方案

1. 定期清理：可以通过GitHub API或手动方式定期清理未标记的旧镜像。

2. 优化构建策略：

   • 确保每次构建都有实际内容变更，避免重复构建相同内容
   • 检查工作流程中是否有重复标记的情况

3. 理解预期行为：认识到这是GitHub容器注册表的正常表现，而非构建工具的问题。

最佳实践建议

1. 在CI/CD流程中加入镜像清理步骤
2. 使用唯一且有意义的标记策略
3. 监控存储空间使用情况
4. 对于生产环境，考虑使用企业级注册表解决方案

总结

Docker Build Push Action 产生的未标记镜像是容器注册表工作方式的正常结果，特别是GitHub容器注册表会明确显示这些内容。开发者应该理解这一机制，并通过优化构建策略和定期清理来管理存储空间。这种现象并不表示构建过程存在问题，而是容器生态系统的一个特性。