-
Bug
-
Resolution: Fixed
-
Critical
-
None
Issues occurs constantly!
Environment:
- master: Jenkins v1.424, Mac OS 10.7.1, AccuRev 4.9.1, AccuRev plugin v0.6.18, JDK 1.6.0_26
- slave: connected via JNLP, Windows 2008 R2, JRE1.6.0_23_x64, AccuRev 4.9.1
- AccuRev settings: Polling set to be on master, show one stream at the time, synch accurev, minimize login, use non-expiring login
- job settings: use workspace, set ONE subpath
Started by user xxx ?????????? ???????? ?? slave_xxx Purging workspace... Workspace purged. Setting ACCUREV_HOME to "C:\Builds" [job_xxx] $ accurev.exe info -H xxx:5050 Currently authenticated with Accurev server as 'user_xxx', not logging in again. Getting a list of streams... [job_xxx] $ accurev.exe show -H xxx:5050 -fx -p depot_xxx -s stream_jkl streams [job_xxx] $ accurev.exe show -H xxx:5050 -fx -p depot_xxx -s stream_ghi streams [job_xxx] $ accurev.exe show -H xxx:5050 -fx -p depot_xxx -s stream_def streams [job_xxx] $ accurev.exe show -H xxx:5050 -fx -p depot_xxx -s stream_abc streams Getting a list of workspaces... [job_xxx] $ accurev.exe show -H xxx:5050 -fx -p depot_xxx wspaces FATAL: null java.lang.NullPointerException at hudson.plugins.accurev.AccurevSCM.checkout(AccurevSCM.java:421) at hudson.model.AbstractProject.checkout(AbstractProject.java:1193) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:175)
Disabling "Show one stream at a time" at the master AccuRev-plugin solved the issue.
[JENKINS-10937] AccuRev: show one stream at the time throws NPE with workspace
Happens with 1.468 as well:
[myjob] $ "C:\Program Files (x86)\AccuRev\bin\accurev.exe" show -H myaccurev:5050 -fx -p mydepot wspaces
pjdarton
added a comment - Yes, the bug is in the plugin, not the core Jenkins code. Until someone fixes the plugin, the bug will remain.
Fortunately there's a good workaround (do not tick the "show one stream at a time" box - or don't build from a workspace), but it's a shame as this facility can make a significant improvement to performance (which is why I wrote it - unfortunately, whilst it worked in my setup, it doesn't work when there's a workspace involved).
Fixing this is on my personal "todo" list (along with the "accurev remove stream" option after doing a snapshot - accurev doesn't like there being 60000 non-hidden snapshots in a depot and gets a tad slow), but I have no idea when I might get the time to fix it and would be very pleased if someone else did it 
pjdarton
added a comment - Yes, the bug is in the plugin, not the core Jenkins code. Until someone fixes the plugin, the bug will remain.
Fortunately there's a good workaround (do not tick the "show one stream at a time" box - or don't build from a workspace), but it's a shame as this facility can make a significant improvement to performance (which is why I wrote it - unfortunately, whilst it worked in my setup, it doesn't work when there's a workspace involved).
Fixing this is on my personal "todo" list (along with the "accurev remove stream" option after doing a snapshot - accurev doesn't like there being 60000 non-hidden snapshots in a depot and gets a tad slow), but I have no idea when I might get the time to fix it and would be very pleased if someone else did it 
Scott Tatum
added a comment - Setting to unassigned as I have no access to Accurev, and am no longer the maintainer of this plugin.
Scott Tatum
added a comment - Setting to unassigned as I have no access to Accurev, and am no longer the maintainer of this plugin. 
Oops.
I don't use workspaces on my setup, so I guess I must have missed that when I did the "one stream at a time" functionality.
I think I see where the bug is: The code does a "getStreams" on the stream "localStream", but if it's going to use a workspace it should have started from the workspace instead (or just gone and fetched the workspace seperately). At present, it's assuming that the workspace is one of the streams that it fetched when it called "getStreams".
I guess the solution would be to enhance the getStreams method so that one can give it a var-args of stream names and have it return a map that contained all those and all their parents. This isn't quite as simple as the current implementation, but shouldn't be too difficult.