[JIRA] (JENKINS-49558) Run stages in separate Docker containers when top level agent declared

4 views
Skip to first unread message

awiddersheim@hotmail.com (JIRA)

unread,
Feb 14, 2018, 12:49:02 PM2/14/18
to jenkinsc...@googlegroups.com
Andrew Widdersheim created an issue
 
Jenkins / New Feature JENKINS-49558
Run stages in separate Docker containers when top level agent declared
Issue Type: New Feature New Feature
Assignee: Andrew Bayer
Components: pipeline-model-definition-plugin
Created: 2018-02-14 17:48
Priority: Minor Minor
Reporter: Andrew Widdersheim

When specifying either docker or dockerfile as the top level agent this will run the entire pipeline and all of it's stages in the same container instance created at the beginning.

pipeline {
    agent {
        docker {
            image 'python3.6'
        }
    }
    /* These stages all run in the same python3.6 container
     * created at the beginning of the pipeline.
     */
    stages {
        stage('Stage 1') {
            steps {
                sh 'echo foo'
            }
        }
        stage('Stage 2') {
            steps {
                sh 'echo bar'
            }
        }
    }
}

 
It would be nice if there were some setting to run each stage in it's own container instance.

pipeline {
    agent {
        docker {
            image 'python3.6'
            runPerStage true
        }
    }
    /* These stages all create their own python3.6 container
     * created at the beginning of each stage.
     */
    stages {
        stage('Stage 1') {
            steps {
                sh 'echo foo'
            }
        }
        stage('Stage 2') {
            steps {
                sh 'echo bar'
            }
        }
    }
}

Additionally, it would be nice to declare on a per stage basis if a new container instance is needed while other stages can use the instance created at the top level.

pipeline {
    agent {
        docker {
            image 'python3.6'
        }
    }
    stages {
        /* This stage creates it's own python3.6 container instance. */
        stage('Stage 1') {
            agent {
                docker {
                    createNew true
                }
            }
            steps {
                sh 'echo foo'
            }
        }
        /* This stage uses the python3.6 container instance created
         * at the top level.
         */
        stage('Stage 2') {
            steps {
                sh 'echo bar'
            }
        }
    }
}

Finally, when declaring a top level docker or dockerfile agent and later specifying a stage level docker or dockerfile agent Jenkins will try and do a docker-in-docker type thing breaking the pipeline and doesn't seem to handle this at all.

It would be nice to have the top level agent as the default container used for stages but if a stage declares it's own agent than that container is used instead. This seem to match more closely to how agent works when not using docker or dockerfile.

pipeline {
    agent {
        docker {
            image 'python3.6'
        }
    }
    stages {
        /* This stage creates it's own python2.7 container instance. */
        stage('Stage 1') {
            agent {
                docker {
                    image 'python2.7'
                }
            }
            steps {
                sh 'echo foo'
            }
        }
        /* This stage uses the python3.6 container instance created
         * at the top level.
         */
        stage('Stage 2') {
            steps {
                sh 'echo bar'
            }
        }
    }
}
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

awiddersheim@hotmail.com (JIRA)

unread,
Feb 14, 2018, 12:55:05 PM2/14/18
to jenkinsc...@googlegroups.com
Andrew Widdersheim commented on New Feature JENKINS-49558
 
Re: Run stages in separate Docker containers when top level agent declared

Just to add to this some, it is possible to have each stage run in it's own container instance but requires setting agent on every stage which can become very verbose and not DRY.

awiddersheim@hotmail.com (JIRA)

unread,
Feb 15, 2018, 2:50:04 PM2/15/18
to jenkinsc...@googlegroups.com

Another annoying scenario I just noticed is you are not trying to execute a stage in lightweight executor as to not tie up anything. For example:

pipeline {
    agent {
        docker {
            image 'python3.6'
        }
    }
    stages {
        stage('Foo') {
            steps {
                sh 'echo foo'
            }
        }
        stage('Verify') {
            agent none
            steps {
                input(
                    message: "Should we update production?"
                )
            }
        }
    }
}

andrew.bayer@gmail.com (JIRA)

unread,
Feb 15, 2018, 3:10:02 PM2/15/18
to jenkinsc...@googlegroups.com

Andrew Widdersheim - that's a separate thing: JENKINS-40966. Which, regrettably, I don't yet have a solution for. I think JENKINS-46809 will get part of the way there - it'll let you do a set of stages that all use the same agent and workspace, with agent none specified at the top level, but still go without an agent on a separate stage.

awiddersheim@hotmail.com (JIRA)

unread,
Feb 15, 2018, 3:12:02 PM2/15/18
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Feb 15, 2018, 3:14:02 PM2/15/18
to jenkinsc...@googlegroups.com

Yeah, that's the docker-in-docker one - if you have a top-level Docker or Dockerfile agent, you're stuck on that agent for all stages, due to limitations in the Docker Pipeline plugin.

andrew.bayer@gmail.com (JIRA)

unread,
Feb 20, 2018, 5:33:02 PM2/20/18
to jenkinsc...@googlegroups.com
Andrew Bayer started work on New Feature JENKINS-49558
 
Change By: Andrew Bayer
Status: Open In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Feb 20, 2018, 5:33:02 PM2/20/18
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Feb 20, 2018, 5:33:02 PM2/20/18
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Feb 20, 2018, 5:34:01 PM2/20/18
to jenkinsc...@googlegroups.com

Oh, and I went with an option instead of a flag on docker and dockerfile - the option is containerPerStage(). I feel like this may be relevant in other agent types down the road, so wanted to decouple the syntax from the Docker/Dockerfile implementations.

awiddersheim@hotmail.com (JIRA)

unread,
Feb 21, 2018, 8:31:03 AM2/21/18
to jenkinsc...@googlegroups.com

Andrew Bayer sure, makes sense. Looks good to me! Though not sure it helps with comment-328884 at all. That said, you mentioned that issue is related to something else.

scm_issue_link@java.net (JIRA)

unread,
Mar 12, 2018, 3:08:03 PM3/12/18
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Agent.groovy
pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/agent/AbstractDockerAgent.java
pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/options/impl/ContainerPerStage.java
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/AbstractDockerPipelineScript.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/options/impl/ContainerPerStage/help.html
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/AgentTest.java
pipeline-model-definition/src/test/resources/agentDockerContainerPerStage.groovy
pipeline-model-definition/src/test/resources/agentDockerWithoutContainerPerStage.groovy
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/773530a1eade1bb1b4b14845cc9b1f0800d7ad29
Log:
[FIXED JENKINS-49558] Add containerPerStage option

If given with a top-level Docker or Dockerfile agent, the top-level
will magically switch to just a label agent, while each stage without
an explicit agent specified will end up using the root agent
definition with reuseNode enabled. The result will be that each stage
gets a new container. Tada.

This could theoretically cause problems in resuming builds after
upgrade, but not likely, since we actually instantiate the
DeclarativeAgent instance just in time, not at the beginning of the
build. So the new field AbstractDockerAgent#containerPerStageRoot
should get populated correctly.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 12, 2018, 3:09:02 PM3/12/18
to jenkinsc...@googlegroups.com
 

Merged - this'll be in the upcoming Declarative 1.2.8.

Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

scm_issue_link@java.net (JIRA)

unread,
Apr 5, 2018, 8:03:04 PM4/5/18
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Andrew Bayer
Path:

content/doc/book/pipeline/syntax.adoc
http://jenkins-ci.org/commit/jenkins.io/d5c680bc49fd66e799230a89681ccf4078b3c181
Log:
JENKINS-49558 Add doc for newContainerPerStage Declarative option

scm_issue_link@java.net (JIRA)

unread,
Apr 5, 2018, 8:03:04 PM4/5/18
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Liam Newman
Path:
content/doc/book/pipeline/syntax.adoc
http://jenkins-ci.org/commit/jenkins.io/75ca4f256a23448a6e94edbe118ace58d76ab07f
Log:
Merge pull request #1443 from abayer/jenkins-49558

JENKINS-49558 Add doc for newContainerPerStage Declarative option

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:26:01 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages