You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior:
When having no immutability rules in a project configured, changing the tag from one artifact to another in the same repository should work.
Actual behavior:
409 conflict is returned and tag is not updated
The same is true for adding the same tag twice to an artifact.
Steps to reproduce the problem:
POST to the same artifact twice or use the same tag for different artifacts of the repository:
Hi @sberlin ,
This is by design that a same tag is unique within the same repository, thus would avoid mismatch the identifier of an image/artifact when you are pulling by tag.
If you pushing another image within the same repository with same tag, it will automatically been updated to the given new artifact.
If you pushing another image within the same repository with same tag, it will automatically been updated to the given new artifact.
This feature was once also implemented on the v1 API and called retag. Is it possible to re-introduce it? Using the API would be easier for us than pushing with container tools.
Expected behavior:
When having no immutability rules in a project configured, changing the tag from one artifact to another in the same repository should work.
Actual behavior:
409 conflict is returned and tag is not updated
The same is true for adding the same tag twice to an artifact.
Steps to reproduce the problem:
POST to the same artifact twice or use the same tag for different artifacts of the repository:
Versions:
Additional context:
The documented behavior on tag immutability defaults is only true for pushing, but surprisingly not for the REST API v2: https://goharbor.io/docs/2.10.0/working-with-projects/working-with-images/create-tag-immutability-rules/
The issue was already brought up in #14954, but not addressed.
I'm only a project admin without access to configs or logs.
The text was updated successfully, but these errors were encountered: