| I got through the plugin source code to get know if an ability to execute a freestyle job in a container other than jnlp, even with predefined fixed name could be simply implemented. Here's my conclusion/findings. The pipeline code (namely ContainerExecDecorator) uses Kubernates (client) to request given command execution directly inside a defined container. On the other hand, a non-pipeline part (KubernetesLauncher) launches with pod with a "standard" jnlp slave running within a container (usually jenkins/jnlp-slave) which register itself as a cloud node and takes a job to execute. As a result, arbitrary steps/commands cannot be executed in the other container as the reverse channel (Jenkins -> Slave/Kubernates) is through the jnlp which is provided by (and within) a jenkins/jnlp-slave container. Nevertheless, I'm new to that code and I could miss or confuse something. In fact, I would like to be wrong as I need that feature for "legacy" freestyle jobs which uses weird upstream Docker containers. @csanchez, could comment if my thesis is right and that feature (precised in my first sentence) couldn't be simply implemented for freestyle jobs? |
