-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Docker Images:
jenkins/jenkins:lts -> 2.89.1
jenkins/jenkins -> 2.93
Plugins:
Docker API Plugin 3.0.14
Docker Common Plugin 1.9
Docker Pipeline 1.1.4
Docker Slave Plugin 1.0.7
docker build-step 1.43
after the update of some plugins and the lts version comes the following error:
java.lang.NullPointerException: uri was not specified at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:204) at com.github.dockerjava.core.DefaultDockerClientConfig$Builder.withDockerHost(DefaultDockerClientConfig.java:368) at io.jenkins.docker.client.DockerAPI.getClient(DockerAPI.java:113) at com.nirima.jenkins.plugins.docker.DockerTemplate.provisionNode(DockerTemplate.java:443) at io.jenkins.docker.pipeline.DockerNodeStepExecution.createNode(DockerNodeStepExecution.java:71) at io.jenkins.docker.pipeline.DockerNodeStepExecution.lambda$start$0(DockerNodeStepExecution.java:48) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Finished: FAILURE
if I downgrade Docker Commons Plugin to v1.8 it works.
- relates to
-
JENKINS-48050
Replace Declarative Docker agent directive with new implementation
-
- In Progress
-
- links to
[JENKINS-48460] When starting a node with dockerNode(), the error "uri was not specified" is thrown
Volker Schukai
added a comment - Thanks for the answer.
The job ran before the last update without problems for months.
jenkinsfile
dockerNode(image: "myimage") {
config:
1.8 works, 1.9 not.
when i update the exeption is thrown
Volker Schukai
added a comment - Thanks for the answer.
The job ran before the last update without problems for months.
jenkinsfile
dockerNode(image: "myimage" ) {
config :
1.8 works, 1.9 not.
when i update the exeption is thrown
Volker Schukai
added a comment - this works with 1.8:
#!/usr/bin/env groovy
dockerNode(image: mysqlWorkerImage) {
stage("test") {
sh "ls"
}
}
this works with 1.8 and 1.9:
node {
docker.withServer() {
docker.image(mysqlWorkerImage).inside() {
....
Volker Schukai
added a comment - this works with 1.8:
#!/usr/bin/env groovy
dockerNode(image: mysqlWorkerImage) {
stage( "test" ) {
sh "ls"
}
}
this works with 1.8 and 1.9:
node {
docker.withServer() {
docker.image(mysqlWorkerImage).inside() {
....
Oh, this is docker-slaves-plugin.
Do ou have both plugin installed ? This introduce a pipeline DSL conflicts.
docker-plugin 1.1 did introduced another implementation for pipeline keyword "dockerNode". I didn't expected this would collide with docker-slaves-plugin, even being maintainer of both plugin I didn't considered this combination.
As both plugins provide comparable features it seems to me you should not have both installed on your jenkins master. Any reason ?
Need to discuss with pipeline folks about this DSL collision issue.
Volker Schukai
added a comment - thank you for your response and your work. I love both plugins.
In principle, such changes are always tragic for existing installations. In my experience, Jenkins is always vulnerable to such problems and when jenkins update is pending, our team is always scared 
for me it would be quite annoying if I had to rewrite and test all jenkins files. but ok.
our use case: we use the docker-slave-plugin as a build process and the docker-plugin to build docker images.
dockerNode(image: mybuilder) {
stage("test") {
scm()
docker.image.build() ....
}
}
With the docker-slave-plugin we can just start a build process on another linux server. Without pain. The setup is very easy and simple.
docker.withserver() does not work as expected to do build-steps on another maschine.
Volker Schukai
added a comment - thank you for your response and your work. I love both plugins.
In principle, such changes are always tragic for existing installations. In my experience, Jenkins is always vulnerable to such problems and when jenkins update is pending, our team is always scared
for me it would be quite annoying if I had to rewrite and test all jenkins files. but ok.
our use case : we use the docker-slave-plugin as a build process and the docker-plugin to build docker images.
dockerNode(image: mybuilder) {
stage( "test" ) {
scm()
docker.image.build() ....
}
}
With the docker-slave-plugin we can just start a build process on another linux server. Without pain. The setup is very easy and simple.
docker.withserver() does not work as expected to do build-steps on another maschine.
So you only use docker-plugin for it's "build docker image" step ?
Can't you just rely on a plain "docker build" shell script ?
Sure, we could also use a script, but we're putting jenkins on top so we do not have everything in scripts.
We have dozens of different jobs and versions (multibranches). we would have to adapt dozens of Jenkinsfiles. adapt, rewrite, tests, .....
that would be very painful for us.
is not it possible to introduce an alias? If dockerNode already uses use an alias or to make the keyword configurable
dockerPipelineVersion(2)
dockerPipelineName('dockerNode2')
Volker Schukai
added a comment - - edited Sure, we could also use a script, but we're putting jenkins on top so we do not have everything in scripts.
We have dozens of different jobs and versions (multibranches). we would have to adapt dozens of Jenkinsfiles. adapt, rewrite, tests, .....
that would be very painful for us.
is not it possible to introduce an alias? If dockerNode already uses use an alias or to make the keyword configurable
dockerPipelineVersion(2)
dockerPipelineName('dockerNode2')
This is a higher level pipeline DSL discussion. As both plugins have been released this this keyword, I have no idea how to make the resolution deterministic.
Volker Schukai
added a comment - Any News? What does this have to do with docker-slaves? I see this exception routinely, purely from docker-plugin.
dockerNode require you to configure 'dockerHost' uri for the docker node you want this agent to run on. Please ensure your pipeline script is set with one (would help you attached sample script to demonstrate this issue in this ticket)
I don't understand how downgrading docker-commons to 1.8 has any impact here.