Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
Jenkins version: 2.164.3, Ubuntu 16.04.4 LTS, builds are running in Docker (versions 19.03.1, 17.12.0-ce and 18.09.7)
Description
Pipeline execution fails intermittently with the attached error. We have multiple builds running on multiple nodes. Some builds seem to always fail on certain nodes, while other builds seems to always work on the same nodes. I can't really narrow it down to any specific nodes or builds. To me this would not indicate an error in the actual pipeline scripts, since they do work on certain nodes.
Attachments
Activity
Krister Jarl
added a comment - No. Our pipeline looks something like this:
pipeline {
agent {
docker {...}
}
stages {...}
post {
always {
deleteDir()
}
}
}
Krister Jarl
added a comment - No. Our pipeline looks something like this:
pipeline {
agent {
docker {...}
}
stages {...}
post {
always {
deleteDir()
}
}
}
François-Xavier Thomas
added a comment - Not sure if related, but we have the same intermittent build failures with the same FilePath error on 2.164.1 with the following block (using the Bitbucket plugin):
post {
always {
script {
notifyBitbucket()
}
}
}
François-Xavier Thomas
added a comment - Not sure if related, but we have the same intermittent build failures with the same FilePath error on 2.164.1 with the following block (using the Bitbucket plugin):
post {
always {
script {
notifyBitbucket()
}
}
}
Log: jenkins_fail_notifyBitbucket.log If there is no workspace in the context at the time the plugin is called you will get this error. I am not familiar with all the internals of declarative pipeline to say why it would work sometimes and not others, but that is what is causing the issue. A workspace has to be available.
Allan BURDAJEWICZ
added a comment - There is a rather unknown step that can be used to check if a workspace actually is allocated in the current context: https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#getcontext-get-contextual-object-from-internal-apis. So a workaround for such kind of scenario can be to do something like this:
post {
always {
script {
if (getContext(hudson.FilePath)) {
deleteDir()
}
}
}
}
Allan BURDAJEWICZ
added a comment - There is a rather unknown step that can be used to check if a workspace actually is allocated in the current context: https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#getcontext-get-contextual-object-from-internal-apis . So a workaround for such kind of scenario can be to do something like this:
post {
always {
script {
if (getContext(hudson.FilePath)) {
deleteDir()
}
}
}
}
Randy Zulueta
added a comment - The above workaround doesn't cover the case when an scm timeout occurred e.g. due to network congestion which results to workspace not created or completed in the build environment.
Steps to replicate:
- Run a build pipeline
- Abort the build run while the Checkout SCM stage is executing.
Randy Zulueta
added a comment - The above workaround doesn't cover the case when an scm timeout occurred e.g. due to network congestion which results to workspace not created or completed in the build environment.
Steps to replicate:
Run a build pipeline
Abort the build run while the Checkout SCM stage is executing.
Are you calling deleteDir inside of a node block?