Return the creation timestamp along with the name for each tag
Context
I'd like to point out that for cleanup policies executions most of the time they do .....
In other words, background jobs pings (multiple times) the container registry to get the tags list, to get the creation timestamp for each tag, orders the list, apply the filters and the result list of tags to destroy is simply empty.
"Most of the time here" is here super high like 1115 executions out of 1155 (that's 95+ %).
If we can build the list of tags to destroy in a single API call, eg. returning the list of tags with their creation timestamp, we will improve the whole system by a significant margin. Background jobs for cleanup policies will be way more efficient = more cleanups done per hour which in turn will make us reduce the number of jobs necessary to process all the cleanups on gitlab.com in GitLab
In short, a tags list with the creation timestamp has a high ~performance impact on the rails backend features.
Proposal
Return the creation timestamp along with the name for each tag.
In addition, add the size of the image to the response as well. Related to gitlab#223732[9.png] (comment 931938776). Doing so, this endpoint would become useful not just for cleanup policies but also for the dry run feature and the tag list/detail view (where we currently need 2 network requests to fetch the manifest and configuration of an image in order to tell the creation timestamp and size).
Status
We are currently blocked on this until the migration and deployment of the container registry has been completed. See the below quote from @jdrpereira from &5683 (comment 760753089)
Once we complete the registry migration Phase 1 and start Phase 2, on the Rails side, we'll be able to programmatically determine if a given container repository is migrated or not. With the result, we can then fork the registry client on the Rails side so that there is one to interact with the old registry (and compatible with third-party registries on self-managed) and another to interact with the new registry (powered by the metadata database).
Cleanup policies would then be able to use this new client whenever applicable. As soon as we start Phase 2, all new repositories from that moment onwards will be created on the database (plus all others that were already created during Phase 1), and old ones will be migrated gradually. So cleanup policies will be able to use the new registry capabilities for more and more container repositories, all automatically.
Related to gitlab#325760 (closed).