-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat(kubernetes): Surface Image Pull Errors in Kubernetes Runtime #279
Conversation
Pulling is a Docker-specific term that does not apply to the Kubernetes runtime. Preparing is more generic and can apply to both.
Codecov Report
@@ Coverage Diff @@
## master #279 +/- ##
==========================================
- Coverage 78.91% 78.77% -0.14%
==========================================
Files 67 67
Lines 4870 4952 +82
==========================================
+ Hits 3843 3901 +58
- Misses 884 903 +19
- Partials 143 148 +5
|
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.
LGTM 🐬
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.
thank you!
can you please fix up the new linting errors? we added/modified some rules that triggered a few issues. |
57cb4c6
to
8a22f18
Compare
I'm really not sure what to do to replace |
I'm going to break this down into more discrete PRs. As I'm studying issues with the k8s runtime, I'm considering some different ways to subscribe to the event stream related to a build. |
Closing in favor of #331 |
The Docker Runtime surfaces image pull errors naturally because of the blocking synchronous requests to pull an image or start a container.
Kubernetes is asynchronous, so we have to explicitly watch for events to make sure the image pull succeeds in RunContainer.
When we capture a failure event, we can surface the event in the same way as the Docker runtime.
There may be other places where we need to watch for events, so I extracted some of the test logic from WaitContainer to make it reusable.
Also, this changes the init step so it says "Preparing" instead of "Pulling" since the Kubernetes runtime does NOT pull during init.