#1553 seems to work when there is just the jnlp container: after one day of not being able to make a connection (e.g., build has long since completed), the JVM exits, the container exits, and the pod is deleted.
Unfortunately this does not seem to work when additional containers are specified: the jnlp container is marked as exited 1d after it started, but the other container is still sleeping and considered ready, so the pod remains alive, wasting resources.
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy is a difficult read but I could not find any way to fix this. Google hits just talk about manual cleanup. Maybe there could be some sort of liveness probe based on the jnlp container?
#1553 seems to work when there is just the
jnlpcontainer: after one day of not being able to make a connection (e.g., build has long since completed), the JVM exits, the container exits, and the pod is deleted.Unfortunately this does not seem to work when additional containers are specified: the
jnlpcontainer is marked as exited 1d after it started, but the other container is stillsleeping and considered ready, so the pod remains alive, wasting resources.https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy is a difficult read but I could not find any way to fix this. Google hits just talk about manual cleanup. Maybe there could be some sort of liveness probe based on the
jnlpcontainer?