-
Story
-
Resolution: Fixed
-
Major
-
None
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'
}
}
}
}
[JENKINS-48421] Support kubernetes in Declarative Pipeline
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
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
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`.
This is basically handled by the kubernetes plugin's Declarative support.
jstrachan this looks quite similar to the PR you have submitted. Could we do a hangout and compare notes?