• Icon: New Feature New Feature
    • Resolution: Not A Defect
    • Icon: Minor Minor
    • warnings-plugin
    • None

      Hi all,

      I seem to have hit a possible bug with using the Checkstyle plugin for a pipeline project.

      I have checked that the plugins are all working OK for a freestyle project:

      https://groups.google.com/forum/#!topic/jenkinsci-users/RMyO5zYDABM

      (sorry for the cross post)

      Now if I use the following for a pipeline version of the same project:

      stage('RuboCop code analyzer') {
        node {
          sh '/var/lib/jenkins/ci-projects/test/build-scripts/run-rubocop-tests.sh'
      
          publishHTML(target: [
            allowMissing: false,
            alwaysLinkToLastBuild: true,
            keepAll: true,
            reportDir: '/var/lib/jenkins/ci-projects/test/build-reports/',
            reportFiles: 'rubocop-index.html',
            reportName: 'RuboCop HTML Report'
          ])
        }
      }
      
      stage('Scan for Rubocop compiler Warnings') {
        node {
          step([$class: 'WarningsPublisher',
            canResolveRelativePaths: false,
            consoleParsers: [[parserName: 'Rubocop']],
            defaultEncoding: '',
            excludePattern: '',
            healthy: '',
            includePattern: '',
            messagesPattern: '',
            unHealthy: '',
            useStableBuildAsReference: true
          ])
        }
      }
      
      stage('Rubocop CheckStyle Publisher') {
        node {
          step([$class: 'CheckStylePublisher',
            canRunOnFailed: true,
            defaultEncoding: '',
            healthy: '',
            pattern: '',
            unHealthy: '',
            useStableBuildAsReference: true
          ])
        }
      }
      

      When I do a build of the project, I get the following in the console output:

      [CHECKSTYLE] Collecting checkstyle analysis files...
      [CHECKSTYLE] Finding all files that match the pattern **/checkstyle-result.xml
      [CHECKSTYLE] Computing warning deltas based on reference build #95
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] }
      [Pipeline] // stage
      [Pipeline] End of Pipeline
      Finished: SUCCESS

      Now if I click on the build number, I see the following:

      Checkstyle: 0 warnings.
      No warnings since build 1.
      New zero warnings highscore: no warnings for 71 days!
      During parsing an error has been reported.

      So if I click on the error link I get the following message:

      Errors
      No report files were found. Configuration error?

      Yet the build logs tell me that checkstyle has found the report file above.

      Have i missed something here, such as a configuration parameter, or is this a possible bug?

      Kind Regards,

      Keith

      Update:

      If I compare the console output from the freestyle version of the project that generates the Checkstyle warnings OK, and the pipeline version of the same project I get these outputs:

      Freestyle project console output

      14:12:25 [CHECKSTYLE] Collecting checkstyle analysis files...
      14:12:26 [CHECKSTYLE] Finding all files that match the pattern **/rubocop-checkstyle-result.xml
      14:12:26 [CHECKSTYLE] Parsing 1 file in /var/lib/jenkins/workspace/test-freestyle
      14:12:26 [CHECKSTYLE] Successfully parsed file /var/lib/jenkins/workspace/test-freestyle/rubocop-checkstyle-result.xml with 4177 unique warnings and 0 duplicates.
      14:12:27 [CHECKSTYLE] Computing warning deltas based on reference build #65

      Pipeline version console output

      [CHECKSTYLE] Collecting checkstyle analysis files...
      [CHECKSTYLE] Finding all files that match the pattern **/checkstyle-result.xml
      [CHECKSTYLE] Computing warning deltas based on reference build #98

      So it looks like the pipeline version is NOT parsing the xml output file - but the freestyle version is.

      What do I need to do to make the pipeline version parse the said file please?

          [JENKINS-42095] Checkstyle plugin not working in pipeline

          Keith Roberts added a comment -

          I will also add
          [CHECKSTYLE] No files found in " + workspace.getAbsolutePath() + " for pattern: " + filePattern

          That would be a great help for debugging purposes if that's not too much trouble please.

          Keith Roberts added a comment - I will also add [CHECKSTYLE] No files found in " + workspace.getAbsolutePath() + " for pattern: " + filePattern That would be a great help for debugging purposes if that's not too much trouble please.

          Ulli Hafner added a comment - - edited

          Is it ok to close this issue? I think that using the checkstyle plugin right after creating of the checkstyle.xml file should do the trick. (Creating and reading the checkstyle results must be within the same node block in the Jenkinsfile)

          Ulli Hafner added a comment - - edited Is it ok to close this issue? I think that using the checkstyle plugin right after creating of the checkstyle.xml file should do the trick. (Creating and reading the checkstyle results must be within the same node block in the Jenkinsfile)

          Keith Roberts added a comment - - edited

          Hi Ulli,

          That's fine with me if you want to close this.

          Looking at part of the Jenkins build log, this tells me that Jenkins thinks the workspace directory for this pipeline project is WORKSPACE=/var/lib/jenkins/workspace/test

          JOB_NAME=test
          LANG=en_GB.utf8
          LOGNAME=jenkins
          NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat
          NODE_LABELS=master
          NODE_NAME=master
          PWD=/var/lib/jenkins/workspace/test@script
          SHELL=/bin/bash
          SHLVL=5
          USER=jenkins
          WORKSPACE=/var/lib/jenkins/workspace/test 
          

           

          But when Jenkins checks out the SVN repository, it places the code into:

          PWD=/var/lib/jenkins/workspace/test@script

           

          At least I know what is going on now, and how to fix this when it occurs with other pipeline projects.

          Thanks for all your help with this.

          Keith

          Keith Roberts added a comment - - edited Hi Ulli, That's fine with me if you want to close this. Looking at part of the Jenkins build log, this tells me that Jenkins thinks the workspace directory for this pipeline project is WORKSPACE=/var/lib/jenkins/workspace/test JOB_NAME=test LANG=en_GB.utf8 LOGNAME=jenkins NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat NODE_LABELS=master NODE_NAME=master PWD=/var/lib/jenkins/workspace/test@script SHELL=/bin/bash SHLVL=5 USER=jenkins WORKSPACE=/var/lib/jenkins/workspace/test   But when Jenkins checks out the SVN repository, it places the code into: PWD=/var/lib/jenkins/workspace/test@script   At least I know what is going on now, and how to fix this when it occurs with other pipeline projects. Thanks for all your help with this. Keith

          Ulli Hafner added a comment -

          Ok, that means it still does not work if the checkstyle xml creation and the checkstyle publisher are invoked within the same node block? I think I is better if I create at least a test case for our acceptance test suite before I close this issue...

          Ulli Hafner added a comment - Ok, that means it still does not work if the checkstyle xml creation and the checkstyle publisher are invoked within the same node block? I think I is better if I create at least a test case for our acceptance test suite before I close this issue...

          Keith Roberts added a comment - - edited

          I'll try what you have suggested Ulli on a test pipeline project, and let you know if it works or not.

           

          Keith Roberts added a comment - - edited I'll try what you have suggested Ulli on a test pipeline project, and let you know if it works or not.  

          Keith Roberts added a comment - - edited

          Hi Ulli,

          I have tested this now with the following piece of pipeline code:

           

          stage('RuboCop code analyzer') {
            node {
              sh '/var/lib/jenkins/ci-projects/test/build-scripts/run-rubocop-tests.sh'
          
              publishHTML(target: [
                allowMissing: false,
                alwaysLinkToLastBuild: true,
                keepAll: true,
                reportDir: '/var/lib/jenkins/ci-projects/test/build-reports/',
                reportFiles: 'rubocop-index.html',
                reportName: 'RuboCop HTML Report'
              ])
          
              step([$class: 'CheckStylePublisher',
                canRunOnFailed: true,
                defaultEncoding: '',
                healthy: '100',
                pattern: '**/rubocop-checkstyle-result.xml',
                unHealthy: '90',
                useStableBuildAsReference: true
              ])
            }
          } 
          

           

          Running a build I get the following correct output in Jenkins log:

           

          [CHECKSTYLE] Collecting checkstyle analysis files...
          [CHECKSTYLE] Finding all files that match the pattern **/rubocop-checkstyle-result.xml
          [CHECKSTYLE] Parsing 1 file in /var/lib/jenkins/workspace/test
          [CHECKSTYLE] Successfully parsed file /var/lib/jenkins/workspace/test/rubocop-checkstyle-result.xml with 4513 unique warnings and 0 duplicates.
          [CHECKSTYLE] Computing warning deltas based on reference build #120 
          

           

          Now using the exact same configuration, if I delete the symlink that points from:

          /var/lib/jenkins/workspace/test

          to

          /var/lib/jenkins/workspace/test@script

          and run another build, I get the following output in the Jenkins build log:
          [CHECKSTYLE] Collecting checkstyle analysis files...
          [CHECKSTYLE] Finding all files that match the pattern **/rubocop-checkstyle-result.xml
          [CHECKSTYLE] Computing warning deltas based on reference build #121
           

          and Checkstyle gives me an error message:

          During parsing an error has been reported.

          So even when I add the CheckStylePublisher step to the same node where Rubocop runs and creates the rubocop-checkstyle-result.xml output file, when the symlink has gone, it appears that this is breaking Checkstyle, as it cannot then find the rubocop-checkstyle-result.xml file.

          Kind Regards,

          Keith

           

          Keith Roberts added a comment - - edited Hi Ulli, I have tested this now with the following piece of pipeline code:   stage('RuboCop code analyzer') {   node {     sh '/var/lib/jenkins/ci-projects/test/build-scripts/run-rubocop-tests.sh'     publishHTML(target: [       allowMissing: false,       alwaysLinkToLastBuild: true,       keepAll: true,       reportDir: '/var/lib/jenkins/ci-projects/test/build-reports/',       reportFiles: 'rubocop-index.html',       reportName: 'RuboCop HTML Report'     ])     step([$class: 'CheckStylePublisher',       canRunOnFailed: true,       defaultEncoding: '',       healthy: '100',       pattern: '**/rubocop-checkstyle-result.xml',       unHealthy: '90',       useStableBuildAsReference: true     ])   } }   Running a build I get the following correct output in Jenkins log:   [CHECKSTYLE] Collecting checkstyle analysis files... [CHECKSTYLE] Finding all files that match the pattern **/rubocop-checkstyle-result.xml [CHECKSTYLE] Parsing 1 file in /var/lib/jenkins/workspace/test [CHECKSTYLE] Successfully parsed file /var/lib/jenkins/workspace/test/rubocop-checkstyle-result.xml with 4513 unique warnings and 0 duplicates. [CHECKSTYLE] Computing warning deltas based on reference build #120   Now using the exact same configuration, if I delete the symlink that points from: /var/lib/jenkins/workspace/test to /var/lib/jenkins/workspace/test@script and run another build, I get the following output in the Jenkins build log: [CHECKSTYLE] Collecting checkstyle analysis files... [CHECKSTYLE] Finding all files that match the pattern **/rubocop-checkstyle-result.xml [CHECKSTYLE] Computing warning deltas based on reference build #121   and Checkstyle gives me an error message: During parsing an error has been reported. So even when I add the CheckStylePublisher step to the same node where Rubocop runs and creates the rubocop-checkstyle-result.xml output file, when the symlink has gone, it appears that this is breaking Checkstyle, as it cannot then find the rubocop-checkstyle-result.xml file. Kind Regards, Keith  

          Keith Roberts added a comment - - edited

          Hi Ulli,

          It seems like Jenkins creates an empty /var/lib/jenkins/workspace/test directory when the symlink has been deleted.

          If I delete the empty /var/lib/jenkins/workspace/test directory, and re-create the symlink to point from:

          /var/lib/jenkins/workspace/test

          to

          /var/lib/jenkins/workspace/test@script

          then run another build, it all works as expected again.

          So this possibly could be an issue with Jenkins not setting the workspace to the correct path for where a pipeline project's code is getting checked out to? ie. Jenkins is using the workspace path for a freestyle project's location even for a pipeline project?

          HTH,

          Keith

           

           

          Keith Roberts added a comment - - edited Hi Ulli, It seems like Jenkins creates an empty /var/lib/jenkins/workspace/test directory when the symlink has been deleted. If I delete the empty /var/lib/jenkins/workspace/test directory, and re-create the symlink to point from: /var/lib/jenkins/workspace/test to /var/lib/jenkins/workspace/test@script then run another build, it all works as expected again. So this possibly could be an issue with Jenkins not setting the workspace to the correct path for where a pipeline project's code is getting checked out to? ie. Jenkins is using the workspace path for a freestyle project's location even for a pipeline project? HTH, Keith    

          Ulli Hafner added a comment -

          Thanks for the detailed test! I think I can now set up a test in our acceptance test suite that exposes this bug (in the pipeline plugin).

          Ulli Hafner added a comment - Thanks for the detailed test! I think I can now set up a test in our acceptance test suite that exposes this bug (in the pipeline plugin).

          Ulli Hafner added a comment - - edited

          I finally managed it to look into this issue:

          The @script folder in the workspace folder is created if your Jenkinsfile is stored in an SCM. (If the option lightweight checkout is disabled). Checkstyle (and all other tools) are running in the workspace without the @script suffix. So I wonder, why the call run-rubocop-tests.sh produces a checkstyle file in the @script folder, shouldn't the file be also created in the workspace folder without @script?

          So when summing this up: isn't the checkstyle plugin doing the right thing by looking into the folder without @script? All other build files should be available there, too?

          Ulli Hafner added a comment - - edited I finally managed it to look into this issue: The @script folder in the workspace folder is created if your Jenkinsfile is stored in an SCM. (If the option lightweight checkout is disabled). Checkstyle (and all other tools) are running in the workspace without the @script suffix. So I wonder, why the call run-rubocop-tests.sh produces a checkstyle file in the @script folder, shouldn't the file be also created in the workspace folder without @script? So when summing this up: isn't the checkstyle plugin doing the right thing by looking into the folder without @script? All other build files should be available there, too?

          Ulli Hafner added a comment -

          Here the help of the SCM Jenkinsfile entry: Specify where to obtain a source code repository containing your Groovy script. It will be checked out somewhere on the Jenkins master and used to load your Pipeline script. (If you wish to use other files from the same repository during your Pipeline, you will need to check them out separately on some slave; this checkout cannot be reused.)

          Ulli Hafner added a comment - Here the help of the SCM Jenkinsfile entry: Specify where to obtain a source code repository containing your Groovy script. It will be checked out somewhere on the Jenkins master and used to load your Pipeline script. (If you wish to use other files from the same repository during your Pipeline, you will need to check them out separately on some slave; this checkout cannot be reused.)

            drulli Ulli Hafner
            sputnik1 Keith Roberts
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: