dkpro-jwpl
dkpro-jwpl copied to clipboard
#190 - Improve PMD analysis on CI server
- Adds proposed PMD plugin config to demonstrate "analysis caching" works on CI server at UKP.
Note: Requires a change which moves the new PMD plugin section to the pmd profile (marked as TODO), once the CI server executes the PMD goal again via activation of the pmd
profile.
@reckart For what I can see, it seems to use the analysis cache just fine. Randomly taken from the last PR run:
[INFO] Analysis cache loaded [INFO] Analysis cache updated
So the aim of this PR is basically reached. Question: Did you previously activate the pmd
profile? If so, could you re-enable it, so I can put the pmd config back into an overriden profile? Atm - for testing purposes - I added it to the standard build
section. However, I think this should only be run if pmd
profile is actively chosen, e.g. by CI servers.
@reckart @mawiesne should we update this branch so it can be merged ? It looks like things are ramping up for a release soon.
@tgalery Been to Vietnam for 2 weeks and had a tight schedule over there. Having returned now, I just updated this branch to proceed here.
From my perspective, @reckart has to reconfigure the PR- build job to conduct pmd analysis given the new pmd
profile and its related configuration is correctly activated. Last info I have: He disabled Jenkins' pmd plugin (I guess?) for testing purposes, so pmd isn't run twice.
@reckart Could you check this and give this PR a review afterwards?
@tgalery afaik Jenkinses PMD plugin doesn't really run PMD, it just picks up the log files produced by PMD in order to generate a report.
I have added the "pmd" profile to the PR build now. The master build already had it. If PMD is run twice, then that can probably be resolved by a) just adding the additional config in the POM via <pluginsManagement>
, but not adding another execution b) ensuring that the new PMD execution has the same execution ID as the one inherited from the DKPro Parent POM so that it overrides it.
@mawiesne do you have any idea where the plugin stores its cache? I am asking for two reasons
- The Jenkins build is configured to purge all untracked files from the repo and to reset all modified files to the actual remote states before actually building. This is designed to avoid cross-build effects such as having the license checker stumble over heap dump files etc, but also thwarts benign cross-build effects such as the cache you are aiming at.
- The build runs
clean install
meaning that alltarget
folders are deleted.
So I wonder if the loaded cache
line is shown always (i.e. even if there was nothing to load at all) or if the plugin actually stores its data outside the reach of Jenkins and Maven (which would in fact worry me a bit because build jobs are not supposed to do that).