When using jenkinsfile-runner inside Kubernetes such as with Prow/Knative Build in Jenkins X it would be awesome to be able to replicate the kubernetes-plugin style execution of commands in sidecars all from within the exact same pod. e.g.

       

      sh "echo this runs in the same container as the jenkinsfile runner"
      container("selenium") {
         sh "echo this runs in the selenium container"
      } 

      When using pure knative build steps this stuff all works already; but its not yet supported in a Jenkinsfile.

      I understand that the jenkinsfile runner is just 1 container that runs & isn't gonna be able to grok the sidecar containers - but thats fine - we can configure that stuff outside of the jenkisnfile + jenksinfile-runner - but it'd be nice to be able to execute commands in sidecar containers (e.g. via the shell command:

      kubectl exec -it $HOSTNAME -c selenium -- echo "this runs in the selenium continaer" 

       

       

          [JENKINS-54427] Support sidecar containers

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - https://github.com/jenkinsci/remoting/pull/286   is probably a prerequisite

          Jesse Glick added a comment -

          Or we could improve the kubernetes plugin to use a different launch method, say based on the WebSocket underlying kubectl exec, rather than using the JNLP connector. Then there is no need for the jenkinsfile-runner container to expose any ports at all.

          At any rate, jstrachan should understand that in the currently working versions of this, it does not look like the example given in the issue description. Rather, no sh steps may be run in the jenkinsfile-runner container (we set the numExecutors: 0 to emphasize this), and to do any work you use the podTemplate step which launches a separate pod, inside of which you may use node with a label to select the container for the slave.jar, and then container to actually use the desired container. The resulting Pipeline script is rather cumbersome, and the scheduling is inefficient, which is why I would like to deprecate this whole system and introduce an alternative direct-launch step akin to dockerNode in docker-plugin but creating a single-container pod instead.

          Jesse Glick added a comment - Or we could improve the kubernetes plugin to use a different launch method, say based on the WebSocket underlying kubectl exec , rather than using the JNLP connector. Then there is no need for the jenkinsfile-runner container to expose any ports at all. At any rate, jstrachan should understand that in the currently working versions of this, it does not look like the example given in the issue description. Rather, no sh steps may be run in the jenkinsfile-runner container (we set the numExecutors: 0 to emphasize this), and to do any work you use the podTemplate step which launches a separate pod, inside of which you may use node with a label to select the container for the slave.jar , and then container to actually use the desired container. The resulting Pipeline script is rather cumbersome, and the scheduling is inefficient, which is why I would like to deprecate this whole system and introduce an alternative direct-launch step akin to dockerNode in docker-plugin but creating a single-container pod instead.

          Oleg Nenashev added a comment -

          vilacides FYI there are JFR issues outside JENKINS-54342. Somebody needs to scrub them

          Oleg Nenashev added a comment - vilacides FYI there are JFR issues outside JENKINS-54342 . Somebody needs to scrub them

            Unassigned Unassigned
            jstrachan James Strachan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: