Fix context propagation in Kubernetes executor
What does this MR do?
Fix context propagation in Kubernetes executor
Fixes: #27932 (closed)
This change fixes improper context handling in the Kubernetes executor that could lead to resource leaks and failed cancellations.
Changes:
- kubernetes.go:619 - Changed event watcher to use s.Context instead of context.Background(), ensuring the watcher stops when build is cancelled or times out
- Updated TODO comments in exec.go, kubernetes_test.go, and kubernetes_integration_test.go to reflect that context is now properly propagated in these locations
Impact:
- Build cancellation now properly stops all Kubernetes operations
- Event watchers are cleaned up when builds end
- Timeouts are properly respected across all operations
- Reduces resource leaks from hanging watchers
Note: The cleanup function at kubernetes.go:1421 intentionally uses context.Background() as documented in the code - cleanup needs to complete even after build context is cancelled.
Why was this MR needed?
The event watcher in the Kubernetes executor was using context.Background() instead of the build's context. This caused:
- Event watchers to continue running even after builds were cancelled or timed out
- Resource leaks (goroutines, network connections) to accumulate over time
- Build cancellation to not work properly for Kubernetes operations
- Issues with graceful shutdown when the runner is stopped
This is a long-standing issue referenced in the codebase with multiple TODO comments pointing to issue #27932 (closed).
What's the best way to test this MR?
- Automated testing:
- Verify CI pipeline passes
- Existing Kubernetes executor tests should pass
- Manual testing (recommended):
- Start a long-running build on Kubernetes executor
- Cancel the build while it's running
- Verify the event watcher goroutine stops (check for resource cleanup)
- Monitor for goroutine leaks using pprof
- Integration testing:
- Run builds with timeout configured
- Verify timeout is respected and operations stop cleanly
- Check for proper cleanup of Kubernetes resources
The fix is minimal (one line change) and low-risk - it simply uses the correct context that's already available.
What are the relevant issue numbers?
Closes #27932 (closed)