Attempt to fix CI timeouts#1811
Conversation
For some reason, calls to skopeo copy sometimes hang indefinitely. Avoid this issue by specifying --command-timeout with reasonable values (longer for call which must fetch over the network). Signed-off-by: Rolv Apneseth <rolv.apneseth@gmail.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces timeouts to various skopeo copy commands and adds a retry loop to wait for the Docker registry to become ready before logging in, aiming to prevent CI hangs. The reviewer suggested wrapping the openssl s_client readiness check with a timeout command to prevent the check itself from hanging indefinitely if the registry is unresponsive during the TLS handshake.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…oceeding To try and avoid potential races, ensure that the local docker registry is ready before finishing the setup. Signed-off-by: Rolv Apneseth <rolv.apneseth@gmail.com>
|
It does seem like an issue on the registry or maybe the node side of things. Updating the registry image to Test passes fine locally: $ bats --filter "custom image that needs an authentication file" test/system/101-create.bats
test suite: Set up
101-create.bats
✓ create: With a custom image that needs an authentication file
test suite: Tear down
1 test, 0 failures |
1 participant
Attempt to fix CI timeouts with suggestions from #1805.
--command-timeouttoskopeo copycalls so they can't hang forever@debarshiray I chose to go with 10m timeout for the one over the network and 60s for the ones happening locally (in case there's some really slow IO). Did also take the
openssl s_clientapproach like you suggested too. WDYT?