-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update docker_registry2 #7578
Update docker_registry2 #7578
Conversation
40bf586
to
4147bcd
Compare
Could you provide a little bit of context on the update, it looks like the minor update contained some breaking changes? Thanks! |
4147bcd
to
15ae2aa
Compare
Yes. |
bd98523
to
14e32ed
Compare
14e32ed
to
ae3fc02
Compare
Tag 1.17 has been pushed in the meantime, so I added updating to 1.17 in this PR. |
Not sure the docker smoke test is related, can you have a look @jurre? |
@NautiluX yeah that does look related, seems like dockerhub is requiring us to auth for these requests now? Let me re-run them to make sure it wasn't just a hiccup |
right so these requests:
used to be HEAD requests before 1.15, that could explain the difference. |
I tried reproducing the behaviour with a minimal example, doing the same calls that dependabot would do:
Interjected the requests with a proxy and got similar requests than the smoketest:
However, the second GET got a 200 as response, not a 401 as in the smoketest. |
ae3fc02
to
65df421
Compare
managed to get the test running locally, it's succeeding as well. Not sure what's still different to the environment where they run in the GitHub action.
|
@jurre I think I found the problem. When I download the cache and run against it, the test run fails for me locally as well. Looking at the test output in the github action, it says:
My understanding is, for some reason, it uses cached HTTP responses for the GET calls and in the cache there is the 401 response. |
If I understand how the smoke-tests work correctly, I don't think recaching before merging will help since this PR is responsible for the changed responses right? |
Ah, I think that's something about how our e2e tests work, let me ask someone internally |
88ca7df
to
d598a9e
Compare
* Fixes specs that break after 1.15 * Bump to 1.17 to allow paging registry.access.redhat.com based images
* digest API has changed in docker_registry2 with 1.15 * preserving current behavior by extracting the digest header as docker_registry2 <1.15 did
d598a9e
to
a33efb0
Compare
@jurre I verified the docker e2e test works without cache locally, so the PR should be ready to get merged from my perspective. I had to update the digest querying so it behaves as it did with docker_registry2 <1.15. |
Thanks for this fix @NautiluX 🙇 I'll try to get the change out in a bit |
Unfortunately, it seems that with these changes we're now seeing a lot of rate limiting errors, I'm going to revert so we can dig into it more |
@@ -245,7 +245,8 @@ def digest_of(tag) | |||
end | |||
|
|||
def fetch_digest_of(tag) | |||
docker_registry_client.digest(docker_repo_name, tag)&.delete_prefix("sha256:") | |||
manifest = docker_registry_client.manifest(docker_repo_name, tag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it seems like the GET
request to this endpoint ends up counting towards rate-limits whereas the HEAD
request didn't, and since we make a lot of requests from a relatively small set of IP addresses, a lot of our updates ended up failing when I ran this in production :(
Trying to reintroduce the old functionality in docker_registry2 lib: deitch/docker_registry2#95 |
Commenting to add that depending on this new method goes against the spec. See deitch/docker_registry2#98 |
I created #8010 to open this for discussion |
Update docker_registry2
Closes #7562.