-
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
fix(kubernetes): Make Executor TailContainer before RunContainer #277
Conversation
The Kubernetes runtime needs to start asking for logs before the container is created, or logs from short-lived steps might be gone by the time TailContainer starts. The Docker runtime, however, needs to RunContainer first or the docker engine will complain that the container does not exist. So, we use a special `runCtx` to let the Docker Runtime's TailContainer know when RunContainer has finished to allow it to delay pulling logs until the container exists.
Codecov Report
@@ Coverage Diff @@
## master #277 +/- ##
==========================================
- Coverage 78.91% 77.92% -0.99%
==========================================
Files 67 67
Lines 4870 4907 +37
==========================================
- Hits 3843 3824 -19
- Misses 884 943 +59
+ Partials 143 140 -3
|
This makes use of a new Is there a better signaling primitive to synchronize the stream+TailContainer go routine with when the outer scope finishes RunContainer? |
Oops. I hit the wrong button and closed it. :( |
I switched from a Context to a plain channel. That feels a bit cleaner. |
The purpose is a bit clearer this way
1043387
to
9973e77
Compare
> if statements should only be cuddled with assignments (wsl)
I'm not confident this is a good fix. I'm looking at alternatives |
Alternate version in #286 |
Closing in favor of #303 |
This should make Kubernetes log capture more robust without changing the behavior for the Docker runtime.
The Kubernetes runtime needs to start asking for logs before the container is created, or logs from short-lived steps might be gone by the time TailContainer starts.
The Docker runtime, however, needs to RunContainer first or the docker engine will complain that the container does not exist. So, we use a special channel to let the Docker Runtime's TailContainer know when RunContainer has finished to allow it to delay pulling logs until the container exists.