-
Bug
-
Resolution: Unresolved
-
Blocker
-
None
-
CloudBees Docker Workflow 1.2
Workflow 1.10.1
Jenkins 1.609.1
arch linux
I had a node with docker installed - yet docker workflow was failing with
/scratch/jenkins/workspace/myjob/.954d8efa/script.sh: line 2: docker: command not found
yet docker was available on this node and in the path (as verified by sh 'which docker;docker version'
It transpired that docker-workflow was spinning up another node unescearily and this node did not have docker installed - hence the failure.
After some discussion with jglick we found that the node with docker on did not set the HOME environment variable.
The workaround was to wrap the docker commands with withEnv(['HOME='+pwd()]).
The plugin should explicitly state why it is spawing a new node - to help the user understand, and should probably not rely on the HOME environment variable being set to determine if it can use docker
- links to
[JENKINS-31225] docker.build fails with if HOME is not set.
| Description |
Original:
I had a node with docker installed - yet docker workflow was failing with {noformat} /scratch/jenkins/workspace/myjob/.954d8efa/script.sh: line 2: docker: command not found {noformat} yet docker was available on this node and in the path (as verified by {{sh 'which docker;docker version'}} It transpired that docker-workflow was spinning up another node unescearily and this node did not have docker installed - hence the failure. After some discussion with [~jglick] we found that the node with docker on did not set the {{HOME}} environment variable. The workaround was to wrap the docker commands with {{withEnv(['HOME='+pwd()]) }}. The plugin should explicitly state why it is spawing a new node - to help the user understand, and should probably not rely on the {{HOME}} environment variable being set to determine if it can use {{docker}} |
New:
I had a node with docker installed - yet docker workflow was failing with {noformat} /scratch/jenkins/workspace/myjob/.954d8efa/script.sh: line 2: docker: command not found {noformat} yet docker was available on this node and in the path (as verified by {{sh 'which docker;docker version'}} It transpired that docker-workflow was spinning up another node unescearily and this node did not have docker installed - hence the failure. After some discussion with [~jglick] we found that the node with docker on did not set the {{HOME}} environment variable. The workaround was to wrap the docker commands with {{withEnv(\['HOME='+pwd()])}}. The plugin should explicitly state why it is spawing a new node - to help the user understand, and should probably not rely on the {{HOME}} environment variable being set to determine if it can use {{docker}} |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Remote Link | New: This issue links to "PR 52 (Web Link)" [ 14656 ] |
| Workflow | Original: JNJira [ 166454 ] | New: JNJira + In-Review [ 185649 ] |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
| Resolution | Original: Fixed [ 1 ] | |
| Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
I believe I have hit this from time to time.
My solution in that case was to have a Dockerfile that adds a user:
example:
https://github.com/jenkinsci/jenkins-design-language/blob/master/Dockerfile
And use the image that produces (not sure if exactly related though).
An echo message when starting a new node would be useful. The issue here is probably most easily resolved by updating the Workflow dependency to 1.9 (or newer), and checking for NODE_NAME, which is now unconditionally defined in the scope of any node block.