Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-48421

Support kubernetes in Declarative Pipeline

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In scope

      • Define a pod for the pipeline with all the same directives as found in pod templates
      • When the Pipeline is run the pod is started on Kubernetes
      • When the Pipeline executes, the steps are run on the container specified in the agent container block
        • The container named in these blocks must be defined in the pod template. If it does not exist in the pod template, the pod should not be created and should result in an error.
      • Support top level and stage level agent directive.
      • Pod name is automatically generated by Jenkins
        • pod name is the full name of the Pipeline and its run ID e.g. pipeline/myproject/mypipeline/123
      • Pod is automatically labeled with the pipelineName and runId

      Out of scope

      • Anything else not outlined in this ticket
      • Loading the pod template from a YAML file (this can come later)

      Example

      pipeline {
        pod {
          containers {
            container {
              name 'database-testing'
              image 'mysql'
            }
            container {
              name 'build'
              image 'maven'
            }
            container {
              name 'deploy'
              image 'bash'
            }
          }
        }
        agent none
        stages {
          stage('build app') {
            agent {
              container { 
                name 'build' 
              } 
            }
            steps {
              sh 'mvn clean install'
              stash 'app' 'target/*.war'
            }
          }
          stage('build app') {
            agent {
              container { 
                name 'build' 
              } 
            }
            steps {
              unstash 'app'
              sh './deploy.sh'
            }
          }
        }
      }
      

        Attachments

          Activity

          Hide
          jamesdumay James Dumay added a comment -

          James Strachan this looks quite similar to the PR you have submitted. Could we do a hangout and compare notes?

          Show
          jamesdumay James Dumay added a comment - James Strachan this looks quite similar to the PR you have submitted . Could we do a hangout and compare notes?
          Hide
          jstrachan James Strachan added a comment -

          Sure sounds good. A few immediate thoughts on the example

          • we've traditionally put the configuration inside a kubernetes block inside agent up to now rather than top level; I wonder should it stay inside agent?
          • I'd like to support these use cases:
            • referring to a pod template by name (which I think `agent { label "foo"}` is the current canonical answer
            • inheriting from a pod template by name (via `inheritFrom "foo"` or something inside pod) then overriding something (e.g. changing a named conrtainers image or adding a new container)
            • defining the complete PodTemplate inline like your example
            • also define other things in the pod like Volumes (which could be secret, host or PVC based volumes) and volume mounts & env vars on containers
          Show
          jstrachan James Strachan added a comment - Sure sounds good. A few immediate thoughts on the example we've traditionally put the configuration inside a kubernetes block inside agent up to now rather than top level; I wonder should it stay inside agent? I'd like to support these use cases: referring to a pod template by name (which I think `agent { label "foo"}` is the current canonical answer inheriting from a pod template by name (via `inheritFrom "foo"` or something inside pod) then overriding something (e.g. changing a named conrtainers image or adding a new container) defining the complete PodTemplate inline like your example also define other things in the pod like Volumes (which could be secret, host or PVC based volumes) and volume mounts & env vars on containers
          Hide
          ndeloof Nicolas De Loof added a comment -

          As your sample pipeline relies on `stash` to reuse files between steps, what's the benefit to define a "pod" here with multiple containers, and not just container(s) per step ? Using a pod here as suggested only makes the build payload a monolith that  will be more constraining to distribute on a cluster. It only makes sense when one need two containers to run with shared namespace, i.e. for sample to access a `selenium` container from a `maven` one as `localhost:4444`.

           

           

          Show
          ndeloof Nicolas De Loof added a comment - As your sample pipeline relies on `stash` to reuse files between steps, what's the benefit to define a "pod" here with multiple containers, and not just container(s) per step ? Using a pod here as suggested only makes the build payload a monolith that  will be more constraining to distribute on a cluster. It only makes sense when one need two containers to run with shared namespace, i.e. for sample to access a `selenium` container from a `maven` one as `localhost:4444`.    
          Hide
          abayer Andrew Bayer added a comment -

          This is basically handled by the kubernetes plugin's Declarative support.

          Show
          abayer Andrew Bayer added a comment - This is basically handled by the kubernetes plugin's Declarative support.

            People

            • Assignee:
              abayer Andrew Bayer
              Reporter:
              jamesdumay James Dumay
            • Votes:
              19 Vote for this issue
              Watchers:
              34 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: