Return the manifest digest in Registry.push()

[hanikesn]

It's often important to correctly identify a recently uploaded artifact. The current Registry.push() method, only returns an empty
response with the following headers:

{
  'Location': '/v2/XXXX//blobs/sha256:ee7dafd624ee5b0e5a8346730bdb319002aef13190489ffe7832c65816f9e63b',
  'Docker-Distribution-Api-Version': 'registry/2.0',
  'Docker-Content-Digest': 'sha256:ee7dafd624ee5b0e5a8346730bdb319002aef13190489ffe7832c65816f9e63b',
  'X-GUploader-UploadID': 'XXXXXX',
  'Content-Length': '0',
  'Date': 'Mon, 10 Jun 2024 21:35:38 GMT',
  'Server': 'UploadServer',
  'Content-Type': 'text/html; charset=UTF-8',
  'Alt-Svc': 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000'
}

The digest returned in the headers does not match the digest of the manifest in the registry though, making it impossible to accurately locate it there.

[vsoch]

We could definitely return a collection of artifacts from the entire interaction - my suggestion would be to put down exactly what you want, make a data class to handle it, and then have it collected in the function here:

oras-py/oras/provider.py

Line 675 in fd8a83c

def push(

It's quite a good idea.

[tarilabs]

I think this could be closed following:

• core: make push response the one pertaining to Manifest (not config #146

as it would now return the response+headers including sha of the actual OCI Manifest as demonstrated by this test case:

• b8c4885#diff-bb68e61df7e381a3beb8607a94a5f492ad9e321e0146645448e7b421400973cbR83

...sorry I didn't realize this was logged when I submitted the PR 😅

@vsoch kindly consider closing this github issue as resolved.
What about having a fresh release in pypi? This would avoid the need for end-user to pull the library changes straight from main?

[vsoch]

Happy to close it - the reason I haven't done a new release yet is because I was waiting for some time to pass to test the new auth backend (not the release bump is a minor patch but still a larger jump than we normally do). If you think it's well tested and good to go I can go ahead.

[tarilabs]

to test the new auth backend

Is there a issue tracker of the tests which would be required for it, please?
Happy to try contribute my part :)

[vsoch]

We don't have an issue for it - I was mostly keeping it as is (and holding off release) until enough people had been using the new branch. In practice it's hard to test these specific cases because there are so many registries.

[tarilabs]

Ack, let see if I can manage to dedicate some cycles to it, will report back 👍
Thinking of trying with (this) Distribution, Zot, Quay... are there others I should consider? These are the ones I typically Interface with.

[vsoch]

That would be fantastic! The registries I use most often are ghcr.io (GitHub packages) and then my communities use GitLab a bit too. The third for me would be Docker Hub. After that, I would say we should consider (maybe find someone to test) each registry provided by a major cloud, minimally AWS / Azure / Google.

[vsoch]

@tarilabs let's pick up discussion here #147