New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-48135] Support multiple containers in declarative pipeline #306

merged 2 commits into from Apr 20, 2018


None yet
7 participants

carlossg commented Apr 6, 2018

Using the yaml syntax

Supersedes #260


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

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


This comment has been minimized.

carlossg commented Apr 9, 2018

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


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


This comment has been minimized.


michaelneale commented Apr 9, 2018

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


This comment has been minimized.

carlossg commented Apr 10, 2018

@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


This comment has been minimized.


abayer commented Apr 10, 2018

@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.


This comment has been minimized.

berni2288 commented Apr 11, 2018

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.


This comment has been minimized.

carlossg commented Apr 11, 2018


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

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


This comment has been minimized.

etiennedi commented Apr 19, 2018

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!


This comment has been minimized.

dcarbajosa commented Apr 19, 2018

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.


This comment has been minimized.

carlossg commented Apr 20, 2018

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

@carlossg carlossg merged commit 3886181 into master Apr 20, 2018

1 check passed

continuous-integration/jenkins/branch This commit looks good

@carlossg carlossg deleted the JENKINS-48135 branch Apr 20, 2018

@carlossg carlossg changed the title from [JENKINS-50533] Support multiple containers in declarative pipeline to [JENKINS-48135] Support multiple containers in declarative pipeline Apr 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment