SVN "is not under version control" failure with Jenkins

Asked 8/8, 2012 at 20:4 Answered 20/2, 2020 at 23:46

I have a project in Jenkins that has many SVN repositories to pull from. Whenever I build, the first build after a workspace clean fails with errors like the one below. Without changing anything, the next build will be successful.

If I set the project to always clean the workspace before the build, it will always fail. Each time, with different SVN repositories.

I tried moving to SVN 1.6, tried verifying that the HTTPS certificate is okay, not sure what else to look for?

ERROR: Failed to parse svn info for     https://subversion.assembla.com/svn/<PROJECT NAME HIDDEN>/trunk
org.tmatesoft.svn.core.SVNException: svn:     '/tmp/data/hudson/jobs/Build_ISO/workspace/ch.ethz.ssh2' is not under version control
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
    at org.tmatesoft.svn.core.wc.SVNWCClient$13.handleError(SVNWCClient.java:3314)
    at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:758)
    at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:741)
at org.tmatesoft.svn.core.wc.SVNWCClient.crawlEntries(SVNWCClient.java:3294)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2498)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2865)
at hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:1023)
at hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:1001)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1212)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1410)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: '/tmp/data/hudson/jobs/Build_ISO/workspace/ch.ethz.ssh2' is not under version control
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:163)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:118)
... 17 more

Godfrey answered 8/8, 2012 at 20:4 Comment(2)

What version of Jenkins are you running? – Prostrate 15/8, 2012 at 6:35

Have you found any solutions? This only happens when 'Local module directory' is set. – Benghazi 11/10, 2012 at 17:25

I know the thread is old and is almost obsolete but that didn't stop from the people like me landing here in search of solution of this popular problem of jenkins. So since now my problem is solved I am posting answer for future use:-

Initial searching gives that problem is due to a bug in some version of SVN plugin, so obvious solution is to change that plugin, the same is pointed out in the links given by @ChrisH. His links were great help. So You can update the svn plugin using following two ways:-

Go to manage plugins and install the update from there.
Download the *.hpi file from this link and place the *.hpi file inside the $JENKINS_HOME/plugins/ folder. If you don't know where $JENKINS_HOME folder is than most chances are it will be a hidden folder in your home directory (for linux).

Once you update the plugin you need to restart the jenkins so that new plugin can take effect.

However if you have downloaded jenkins recently chances are that you don't need to follow above process. Simple go to Manage Jenkins-> Configure System and change the SVN version (to 1.6) from the combo box.

Have fun,

Lipography answered 26/4, 2013 at 9:33 Comment(3)

The last part was my issue; apparently it defaults to 1.5, and changing to 1.6 fixed it – Zellner 3/8, 2016 at 20:23

Very sad, it is almost 2018 and Jenkins' SVN plugin still defaults to 1.4. Do not forget to delete Jenkins' SVN copy and restart Jenkins! – Palladium 7/12, 2017 at 13:52

Wow. You are a hero, @Amit. (You too, @JackMiller). Now it's almost 2019, and freshly downloaded and patched Jenkins still totally fails on svn externals until one changes the working copy version per above. And adds "Additional Credentials" for externals from the same repo and unchecks the baffling "Ignore externals" checkbox. – Soever 24/12, 2018 at 22:28

If you have any svn:externals links in your repository you might be hitting one of these issues:

Prostrate answered 15/8, 2012 at 6:42 Comment(5)

How do I check if I use svn:externals? – Godfrey 15/8, 2012 at 10:27

@Yon: svn pg svn:externals -R from the base directory of a successfully checkedout working copy. – Prostrate 15/8, 2012 at 13:55

Empty response, so not using it I'm guessing. – Godfrey 16/8, 2012 at 6:26

error message would be ERROR: Failed to parse svn info for external in our cases it doesn't say external – Benghazi 11/10, 2012 at 17:29

@Prostrate Iam getting so many external links after using the command you mentioned. How I solve this problem ? plz help – Lipography 26/4, 2013 at 8:41

I faced a similar issue when I was checking out the first repository using Module name and the second repository with "."(no module name). The second checkout was overwriting the first.

The solution that worked for me was: first check out the non module name repository(can be only one), then the non module name repositories.

Caritta answered 11/8, 2016 at 12:23 Comment(0)

If I correctly understand your setting, you have several SVN URLs, and you would like to check out these URLs to a set of folders into your jenkins project workspace. Something like I have here: enter image description here

If you don't define the local module directory, then the workspace will be that. And I think if your checkouts contain overlapping directories, you could have a problem. So always separate checkouts inside one project using module directory setting. Then you need to adjust your build to fit that.

Nadeau answered 10/8, 2012 at 20:39 Comment(2)

Yes, trying to check out multiple URLs. I have defined the local module directory for all of them - they are different from one another. – Godfrey 12/8, 2012 at 5:13

Then maybe you have some trash from previous checkout in workspace root. I have right now no other idea. – Foreyard 14/8, 2012 at 21:35

Here's another possibility: inconsistent URLs in your svn:externals properties. I just identified this in my current project: the externals on . (top) all referenced testmachine-01 but the externals on directory Server referenced testmachine-01.companydomain.com and this was resolving in one way on my development machine and in another on the build server.

Expense answered 7/9, 2015 at 22:50 Comment(0)

This problem resurfaced in 2020! Tried all of the above solutions but none helped. I had to stop Jenkins service and delete the svn external folder in question and restarted. This did the trick. The reason is I had upgraded Jenkins to start using newer data format. That caused many of the jobs to fail with ERROR: Failed to parse svn info for external .... at .. org.tmatesoft.svn.core.SVNException: svn: E200005: 'C:\Jenkins\jobs...' is not under version control

Anamorphism answered 20/2, 2020 at 23:46 Comment(0)

Recommended topics

Hot tags