带有来自 SCM 的 Docker/Dockerfile 代理的 Jenkins 声明式管道

Question

With Jenkins using the Declarative Pipeline Syntax how do i get the Dockerfile ( Dockerfile.ci in this example) from the SCM (Git) since the agent block is executed before all the stages?

pipeline {
    agent {
        dockerfile {
            filename 'Dockerfile.ci'
        }
    }
    stage ('Checkout') {
        steps {
            git(
                url: 'https://www.github.com/...',
                credentialsId: 'CREDENTIALS',
                branch: "develop"
            )
        }
    }
    [...]
}

In all the examples i've seen, the Dockerfile seems to be already present in the workspace.

Answer 1

You could try to declare agent for each stage separately, for checkout stage you could use some default agent and docker agent for others.

pipeline {
    agent none
    stage ('Checkout') {
        agent any
        steps {
            git(
                url: 'https://www.github.com/...',
                credentialsId: 'CREDENTIALS',
                branch: "develop"
            )
        }
    }
    stage ('Build') {
        agent {
            dockerfile {
            filename 'Dockerfile.ci'
        }
        steps {
            [...]
        }
}
    }
    [...]
}

Answer 2

If you're using a multi-branch pipeline it automatically checks out your SCM before evaluating the agent. So in that case you can specify the agent from a file in the SCM.

Answer 3

The answer is in the Jenkins documentation on the Dockerfile parameter :

In order to use this option, the Jenkinsfile must be loaded from either a Multibranch Pipeline or a Pipeline from SCM.

Just scroll down to the Dockerfile section, and it's documented there.

The obvious problem with this approach is that it impairs pipeline development. Now instead of testing code in a pipeline field on the server, it must be committed to the source repository for each testable change. NOTE also that the Jenkinsfile checkout cannot be sparse or lightweight as that will only pick up the script -- and not any accompanying Dockerfile to be built.

I can think of a couple ways to work around this.

1. Develop against agents in nodes with the reuseNode true directive. Then when code is stable, the separate agent blocks can be combined together at the top of the Jenkinsfile which must then be loaded from the SCM.
2. Develop using the dir() solution that specs the exact workspace directory, or alternately use one of the other examples in this solution .