[JENKINS-48135] Support multiple containers in declarative pipeline

[carlossg]

Using the yaml syntax

JENKINS-48135
Supersedes #260

Example:

pipeline {
  agent {
    kubernetes {
      label 'mypod'
      defaultContainer 'jnlp'
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    some-label: some-label-value
spec:
  containers:
  - name: maven
    image: maven:alpine
    command:
    - cat
    tty: true
  - name: busybox
    image: busybox
    command:
    - cat
    tty: true
"""
    }
  }
  stages {
    stage('Run maven') {
      steps {
        container('maven') {
          sh 'mvn -version'
        }
        container('busybox') {
          sh '/bin/busybox'
        }
      }
    }
  }
}

[Vlatombe]

lgtm. This defaultContainer could be useful as well for regular podTemplate.

[carlossg]

I wouldn't know how to do implement defaultContainer in podTemplate

[abayer]

Why the move to YAML? Just because it's more Kubernetes-ish? Because it doesn't feel Pipeline-ish at all.

[michaelneale]

wouldn't at that point you want to put the kube ish yaml in a yaml file and have the pipeline just point to it? vs a mix of syntaxes in a string

[carlossg]

@abayer because this has been a pain, new java code needs to be written for each possible kubernetes api option. Unless there is a way to generate the Java model automatically from Kubernetes this is always lacking all sorts of features from k8s API

@michaelneale I think that's the preferred option, you can use readFile step, at least in non-declarative. What I'm not sure is whether you can have Jenkins checkout scm to get that yaml file before the pod template is defined, the same way the Jenkinsfile is

[abayer]

@carlossg Ok - I know that can be a pain. So you don't actually parse the YAML, you just pass it off to Kubernetes directly? If so, I think I could write up some code to let you specify the YAML equivalent in Declarative syntax and translate it into a YAML string, if that'd be of any interest to you. Would make sense as a followup, though.

[berni2288]

The possibility to have the Kubernete configuration in a seperate file should be kept tho, such configurations can become quite big and complex and it bloats the Jenkinsfile.

[carlossg]

@abayer

So you don't actually parse the YAML, you just pass it off to Kubernetes directly?

sort of, I load it with the kubernetes-client java library

kubernetes-plugin/src/main/java/org/csanchez/jenkins/plugins/kubernetes/PodTemplateBuilder.java

Line 206 in 097922e

Pod podFromYaml = client.pods()

That gives me model objects, but those are outside the plugin (not jenkins annotated)

Ideally the yaml would be kept in a separate file next to Jenkinsfile ie. Jenkinsagent but I'm not sure if the master would checkout extra files from git or just checks out Jenkinsfile

[etiennedi]

Very interested in this PR as well, we really want to use declarative pipelines as well, but currently the fact that every docker image is the same leads to awkward install steps in each container. Additionally, we currently have to use kubectl inside each container to get the contents of secrets. Just mounting them through the template will be much nicer.

Also +1 on having the yaml file separate, but if this is a big effort I'd be quite happy about inline yaml as a first step and maybe adding the extraction later.

Since everything seems green in this PR, do we have an ETA for when this can/will be merged already? Thanks a bunch and really looking forward!

[dcarbajosa]

Hi, is there a way to not enforce in a declarative pipeline the initial container closure? It would be great to have an agent at pipeline level that can be used in most of the stages but doesn't collide with other agents that might be defined in parallel steps or at specific stage level. The problem with enforcing the initial closure is that if you want to run a stage in another node that is not a container it will break. So it would be really cool if we could have a solution that allows this, as it will optimize the pipelines by reducing the waiting time of procuring an agent. Currently the only way of avoiding this collisions is by defining agents at stage level that is not very optimal and time consuming. Many Thanks in advance.

[carlossg]

@dcarbajosa not following, any example ? maybe better to follow up in jenkins-user mailing list

[hkrpavan]

Can we define parent podTemplate in a shared library for declarative pipelines with out using jenkins config for "inheritFrom" feature?

Let me put the same question like this, Is there any other way rather than defining parent pod template in jenkins config for declarative pipelines and get inherited with child pod defined in yaml in jenkinsfile?

[derekslenk]

So a merge was made, but wasn't the fix? Any plans for this?

[hasmikg]

So a merge was made, but wasn't the fix? Any plans for this?

Actually I have the same question here.