Skip to content

Deprecate support for the DELETE /v2/<name>/tags/reference/<tag> API endpoint

Context

Related to Container Registry OCI Conformance (&10345 - closed). Followup from #1091 (closed).

Problem

The Docker Registry HTTP API V2 Spec, later replaced by the OCI Distribution Spec did not include a tag delete operation, and an unsafe and slow workaround (involving deleting manifests, not tags) had to be used to achieve the same end.

Being a heavily used operation at GitLab, we decided to add a tag deletion operation to our own Container Registry, extending the /v2/ API beyond the scope of the Docker and OCI Distribution Spec. We did so in %12.8 (!51 (merged)). This operation is documented here.

Since then, the OCI Distribution Spec has had some updates and it now contemplates a tag delete operation, using the DELETE /v2/<name>/manifests/<tag> endpoint (source). The lack of support for this endpoint means we were not compliant with the OCI Spec. This was addressed in #1091 (closed), and we now have support for this endpoint as well.

All of this means that at the moment we have two endpoints that provide the exact same functionality, that is:

  • DELETE /v2/<name>/tags/reference/<tag> - The custom GitLab tag delete endpoint introduced in %12.8;
  • DELETE /v2/<name>/manifests/<tag> - The OCI compliant tag delete endpoint introduced in %16.4.

Solution

We should deprecate support for the custom GitLab tag delete endpoint. This should be later removed in %17.0.

Please note that this is related to the internal Container Registry app API, not the public GitLab Container Registry API. The latter uses the former to delete tags, and its functionality will remain unaltered. This is therefore a backstage change. So why bother with a deprecation? It's important for users to be aware of in case any of them have decided to bypass the GitLab API and talk directly to the registry API in order to delete tags.

Edited by Jaime Martinez