-
Bug
-
Resolution: Not A Defect
-
Major
-
Windows 7
Jenkins 1.565.2
Maven Project Plugin 2.6
Subversion Plugin 2.4.3
After updating Jenkins from 1.551 to 1.565.2, some of our Maven-type jobs fail with the following message:
"[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
[FATAL] Non-readable POM D:\Jenkins\Jobs\JobName\workspace\JobName-test: D:\Jenkins\Jobs\JobName\workspace\JobName-test (Access is denied)"
D:\...\JobName-test contains the pom.xml.
It happens when Maven is called through "Invoke top-level Maven targets".
Maven Version: (Default)
Goals: verify -X -f "D:\Jenkins\Jobs\JobName\workspace\JobName-test" -Dparam1=abc -Dparam2=def -Dparam3=10
The Jenkins user account on Windows has all access rights on the Jenkins directories and files.
The odd thing about this is that we have another set of Maven-type jobs that run just fine, with the same kind of build step. The only difference is that those are generated from a template job while the failing ones are not. All of them worked fine before the update.
Unfortunately, reconstruction of this error is somewhat complicated since we have an issue with Jenkins giving no SVN credentials that sometimes aborts the build at an earlier point. ( https://issues.jenkins-ci.org/browse/JENKINS-25149 ) I suspect they might be related because the Jenkins update seems to have triggered them both.
[JENKINS-25147] Cannot access pom.xml directory after Jenkins update
No, they have a (virtual) slave of their own while the failing ones run on master. Virtual meaning they all use the same machine and system, no other machines or VMs. I set that up because we sometimes have large, interdependent jobs cluttering the build queue.
It seems we found a workaround.
First, it seems to be necessary to specify the paths of the settings.xml files in the job itself, even though they are set in the global settings. Previously affected jobs now run again. (However - the other ones derived from the template are fine with the global settings only.)
As to the above error message:
Some jobs, like the one I took the error log from, have their poms in a subdirectory. It seems that the Maven plugin version we had before (lower than 2.6) was somehow satisfied to be given the path "D:\...\subdirectory" instead of "D:\...\subdirectory\pom.xml". That was how the job had been working for about a year. Adding "\pom.xml" solved the problem.
So - problem solved, issue closed, I guess.
even though they are set in the global settings
That's not what "Default" in the job configuration means. The global setting just sets the default for new jobs, and always has.
This is absolutely nothing to do with the credentials plugin. Removing the credentials plugin label and component