fix: reject pushing layers with duplicate titles - #260
Shubham-Padkonde wants to merge 1 commit into
Conversation
Files with the same basename (e.g. src/model.py and lib/model.py) got the same org.opencontainers.image.title, so pulling the artifact wrote both to the same path and the second silently replaced the first. push now raises a ValueError naming both files before anything is uploaded for the second one; unique titles set via an annotation file still work. Signed-off-by: Shubham Padkonde <shubhampadkonde12@gmail.com>
| if annotations: | ||
| layer["annotations"].update(annotations) | ||
|
|
||
| title = layer["annotations"].get(oras.defaults.annotation_title) |
There was a problem hiding this comment.
How does the oras-go client handle this? Arguably there are cases where it might be desired to have the same name that replaces.
There was a problem hiding this comment.
I checked both layers of the Go implementation. The CLI preserves cleaned relative paths and honors title annotations, then oras-go's file.Store.Add returns ErrDuplicateName if that name has already been added to the same store. Thus src/model.py and lib/model.py are distinct there, while two identical effective titles in one push are rejected.
This PR only adds the duplicate-title guard; it does not yet preserve relative paths and therefore is not a complete CLI-parity fix for #217. I have corrected the description to avoid claiming that it fully closes the issue. It also does not prohibit replacing an artifact/tag on a later push.
If retaining duplicate titles inside a single artifact is intentional for the Python API, this rejection needs a different policy. Would you prefer preserving relative paths as the primary fix, or an opt-in guard? I will keep that broader behavior change pending your direction. Source comparison prepared with Codex assistance.
This branch has not been deployed
2 participants
Files with the same basename (e.g. src/model.py and lib/model.py) got the same org.opencontainers.image.title, so pulling the artifact wrote both to the same path and the second silently replaced the first. push now raises a ValueError naming both files before anything is uploaded for the second one; unique titles set via an annotation file still work.
Scope clarification: this is a duplicate-title guard, not the complete relative-path preservation requested in #217. The Go CLI preserves relative paths before rejecting duplicate effective titles. The Python behavior choice is under maintainer discussion.