Hi Ulli,

So reading the docs here:

https://plugins.jenkins.io/checkstyle

it looks like checkstyle does not support pipelines yet?

Works with the freestyle and native m2 build option (activated on goal checkstyle:checkstyle or site)

Could we have this implemented for pipelines as well please?

TIA

Keith

I need to update the wiki pages, the Checkstyle plugin has pipeline support.

The pattern you are specifying in the pipeline is wrong: try **/rubocop-checkstyle-result.xml.

Hi Ulli,

Thanks for your quick reply.

I have tried the following pattern in the pipeline step:

stage('Rubocop CheckStyle Publisher') {
  node {
    step([$class: 'CheckStylePublisher',
      canRunOnFailed: true,
      defaultEncoding: '',
      healthy: '100',
      pattern: '**/rubocop-checkstyle-result.xml',
      unHealthy: '90',
      useStableBuildAsReference: true
    ])
  }
}

When I do a build and click on the build number 104 I get the following output:

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

If I click on the error link I get the following message:

Errors

No report files were found. Configuration error?

Looking at the console output for build 104 I can see the following at the end of the build logs:

Running on master in /var/lib/jenkins/workspace/test
[Pipeline]

[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 #103
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: SUCCESS

Please kindly see the screenshots attached below.

So it looks to me like the rubocop-checkstyle-result.xml is not getting parsed to create the output results?

Regards,

Keith

Where is the file rubocop-checkstyle-result.xml located?

It's in the root of the projects workspace:

/var/lib/jenkins/workspace/test@script/rubocop-checkstyle-result.xml

[jenkins@ci test@script]$ pwd
/var/lib/jenkins/workspace/test@script
[jenkins@ci test@script]$ 
[jenkins@ci test@script]$ ls -l rubo*
-rw-r--r--. 1 jenkins jenkins 1003911 Feb 17 09:49 rubocop-checkstyle-result.xml
[jenkins@ci test@script]$ 

I'm wondering why the log contains the message

Running on master in /var/lib/jenkins/workspace/test

Maybe this is the problem? I need to update the logging so we see the actual path the plugin searches the files in.

There is only one Jenkins instance - the localhost master process I think that is referring to.

I agree that some extra logging might help identify what's going on here.

But do you have a folder /var/lib/jenkins/workspace/test and /var/lib/jenkins/workspace/test@script?

Yes - all present there:

[jenkins@ci ~]$ pwd
/var/lib/jenkins
[jenkins@ci ~]$ tree -a -L 1 workspace
workspace
├── test
├── test-freestyle
├── test@script
├── test@tmp
└── test-warnings

Hi Ulli,

Jenkins freestyle projects are checked out under:

/workspace/test

whereas the pipeline version of the same project is checked out under:

/workspace/test@script

HTH

Keith

Hi Ulli,

When you mentioned does the /var/lib/jenkins/workspace/test/ directory exist, that reminded me that pipeline projects use a different root directory than freestyle projects.

It looks like the plugin is still looking for the *.xml file under the location for a freestyle project - not the new location for pipelines which have @script added to their root directory.

I did a test by symlinking the rubocop-checkstyle-result.xml file from:

/var/lib/jenkins/workspace/test@script/rubocop-checkstyle-result.xml

to

/var/lib/jenkins/workspace/test/rubocop-checkstyle-result.xml

and Checkstyle works OK now.

The console log output shows the plugin is looking in the freestyle project place for the configuration file:

{color:#59afe1}Running on master in /var/lib/jenkins/workspace/test
[Pipeline] {
[Pipeline] step
[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 4461 unique warnings and 0 duplicates.
[CHECKSTYLE] Computing warning deltas based on reference build #105
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: SUCCESS
{color}

I guess for now I will have to create a symlink for the pipeline projects, until this issues has been resolved?

Is it worth updating the wiki docs with this fix as well, so others don't get caught out with this?

Thanks for all your help.

Keith

Hi again Ulli,

This message threw me a little bit:

[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 #163

I read that as the file was actually found.

Maybe that could be changed to:

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

Possibly another enhancement might be to look in a pipeline's root directory as well, if the file is not found
first in the freestyle's project root directory?

Thanks for these report plugins.

This will certainly keep the dev's happy with all these reports!

Kind Regards,

Keith

Thanks for the clarification of the message! As a non native speaker it is sometimes too easy to pick the wrong words...

I will also add

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

I'll need to investigate how I can determine the output path of the result files in pipeline projects. I wonder why this has not yet been reported. A lot of people using Checkstyle (and the other tools) in a pipeline. Maybe something in your script is different from the standard.

BTW: are you also reporting test results using the JUnit plugin? There should be the same problem...

I found something in the mailing list archives:
https://groups.google.com/forum/#!topic/jenkinsci-users/513qLiYlXHc

Seems that there will be a new workspace for each node. I.e., you need to place the checkstyle publisher code right below the checkstyle creation code, then the right workspace should be used for both tasks.

Hi Ulli,

I'm not using the JUnit plugin for reporting tests as this is a Ruby project.

The Brakeman plugin has worked OK all the time so far.

As I only build on the master Jenkins node this has only ever been used for freestyle projects:

/var/lib/jenkins/workspace/test/

and

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

gets used as the root directory when I create a pipeline project.

I have deleted the /var/lib/jenkins/workspace/test/ directory and created a symlink to:

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

So that now points the checkstyle plugin to the pipeline's workspace and all seems to be working fine now.

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.

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)

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

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...

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

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

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

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?

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.)