Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59279

Required context class hudson.FilePath is missing

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • pipeline
    • 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

          zuluetar 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:

          1. Run a build pipeline
          2. Abort the build run while the Checkout SCM stage is executing.
          zuluetar 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.

          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 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() } } } }
          slide_o_mix Alex Earl added a comment -

          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.

          slide_o_mix Alex Earl added a comment - 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.

          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

          fxthomas 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
          elephantscatching Krister Jarl added a comment -

          No. Our pipeline looks something like this:

          pipeline {
            agent {
              docker {...}
            }
            stages {...}
            post {
              always {
                deleteDir()
              }
            }
          }
          
          elephantscatching Krister Jarl added a comment - No. Our pipeline looks something like this: pipeline { agent { docker {...} } stages {...}   post {   always {      deleteDir()     }   } }
          slide_o_mix Alex Earl added a comment -

          Are you calling deleteDir inside of a node block?

          slide_o_mix Alex Earl added a comment - Are you calling deleteDir inside of a node block?

          People

            Unassigned Unassigned
            elephantscatching Krister Jarl
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

              Created:
              Updated: