The current PUT manifest implementation is inefficient when multiple tags need updated to point to the same digest. Additionally, the current spec does not have a solution when the manifest does not use sha256 (upload manifest with blake3, then push tag, it'd hash as sha256)
I propose updating the PUT manifest to allow for multiple tags:
PUT /v2/<name>/manifests/<digest>?tag=v3&tag=v3.1&tag=v3.1.2&tag=latest
The response from the registry will include a header OCI-Tags=v3,v3.1,v3.1.2,latest to confirm which tags the registry successfully created.
This proposal:
- Allows for more efficient tag creation paths when multiple tags need created
- Allows specifying hashing algorithm for a given tag
- Easy opt-in for registries -> if
OCI-Tags is not returned, clients fall back to existing tag push.
While there are solutions here that would be more "pure" with regards to HTTP specs (maybe doing a PATCH for tags), I view this solution has having less friction to implement.
The current
PUT manifestimplementation is inefficient when multiple tags need updated to point to the same digest. Additionally, the current spec does not have a solution when the manifest does not usesha256(upload manifest with blake3, then push tag, it'd hash as sha256)I propose updating the PUT manifest to allow for multiple tags:
The response from the registry will include a header
OCI-Tags=v3,v3.1,v3.1.2,latestto confirm which tags the registry successfully created.This proposal:
OCI-Tagsis not returned, clients fall back to existing tag push.While there are solutions here that would be more "pure" with regards to HTTP specs (maybe doing a PATCH for tags), I view this solution has having less friction to implement.