Container Registry API: Align permissions with UI and documentation
Problem to solve
From: https://gitlab.com/gitlab-org/gitlab-ce/issues/55978#note_145404978
The Container Registry API for deleting a tag is currently out of sync with the permissions in the UI. Developers should all have the ability to delete a tag using the API:
- DELETE /projects/:id/registry/repositories/:repository_id/tags/:tag_name
In addition, we need to update the Container Registry API documentation to reflect the actual action of the API call. The tags are not actually deleted by the API, they are decoupled from the image. So, we should clarify that for to remove the actual blobs the user should run garbage collection registry garbage-collect
(ideally with -m
) or the pruner docker-distribution-pruner
Target audience
Further details
Use cases
- A user, with developer, maintainer or administrator rights may utilize the API to delete a repository tag
- User navigates to GitLab documentation and is able to understand how the API works and what the expected outcome is.
- A user with maintainer or administrator rights may utilize the API to bulk delete a set of tags.
Goals
- At GitLab, we document and understand the permissions for each API for Package
- For a given feature, the API and UI follow the same permissions
Proposal
Allow deleting tags from the API using the same permissions as we allow from the UI
Permissions and Security
Action | Location | Guest | Reporter | Developer | Maintainer | Administrator |
---|---|---|---|---|---|---|
List registry repositories | API | x | x | x | ||
Delete registry repository | API | x | x | x | ||
List repository tags | API | x | x | x | ||
Get details of a repository tag | API | x | x | x | ||
Delete a repository tag | API | x | x | x | ||
Delete repository tags in bulk | API | x | x |
Documentation
- https://docs.gitlab.com/ce/api/container_registry.html#delete-repository-tags-in-bulk
- https://docs.gitlab.com/ee/user/permissions.html
What does success look like, and how can we measure that?
Success would be that our users can rely on our documented permissions and functionality.