I take the Test-Task for the Snapshot on my TODO list. I must wait until our Jenkins is idle and can be restarted.

Is it correct to follow the steps of Deploying a custom build of a core plugin this way?

1. /etc/init.d/jenkins stop
2. cd $JENKINS_HOME/plugins
3. mv cvs.jpi cvs.bak
4. rm -rf cvs
5. wget 'https://jenkins.ci.cloudbees.com/job/plugins/job/cvs-plugin/202/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.11-SNAPSHOT/cvs-2.11-SNAPSHOT.hpi'
6. mv cvs-2.11-SNAPSHOT.hpi cvs.jpi
7. test -f cvs.jpi.pinned && echo "cvs.jpi.pinned exists" || (echo "pinned" > cvs.jpi.pinned && echo "cvs.jpi.pinned touched")
8. /etc/init.d/jenkins start

After testing I would revert to the 2.09 version of the CVS Plug-in via Plugin-Manager and restart Jenkins.

I didn't test a snapshot before. Will this steps work?

EDIT:

• touch pinned file
• remove expaned cvs plugin directory
• single quote URL (and fix a typo)
• update snapshot to #202

After step 5, if you don't already have a cvs.jpi.pinned file, then:
5.a. echo 'pinned' > cvs.jpi.pinned

Otherwise this looks good.

Ok. I add the pinned step. The currently running Jobs take several hours. I can try the snapshot this evening/afternoon or may be later. I have to talk with my team.

I'm getting another stacktrace with this change

java.lang.NullPointerException
at hudson.model.User.get(User.java:321)
at hudson.model.User.get(User.java:299)
at hudson.model.User.get(User.java:364)
at hudson.scm.CVSChangeLogSet$CVSChangeLog.getAuthor(CVSChangeLogSet.java:340)
at hudson.scm.CVSChangeLogSet$CVSChangeLog.canBeMergedWith(CVSChangeLogSet.java:185)
at hudson.scm.CvsLog.saveChange(CvsLog.java:415)
at hudson.scm.CvsLog.processComment(CvsLog.java:331)
at hudson.scm.CvsLog.mapCvsLog(CvsLog.java:95)
at hudson.scm.AbstractCvs.executeRlog(AbstractCvs.java:734)
at hudson.scm.AbstractCvs.access$100(AbstractCvs.java:80)
at hudson.scm.AbstractCvs$2.invoke(AbstractCvs.java:663)
at hudson.scm.AbstractCvs$2.invoke(AbstractCvs.java:660)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2420)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Cause seems to be https://github.com/jenkinsci/cvs-plugin/blob/18c7ccc7f56856139eaa4c2d66e492b5fe7eb862/src/main/java/hudson/scm/CVSChangeLogSet.java#L185
(User cannot be built on slave jvm)

May be this change is the reason?

https://github.com/jenkinsci/cvs-plugin/commit/18c7ccc7f56856139eaa4c2d66e492b5fe7eb862#diff-139a187ec59bc7eb8470bf61259e123bL339

May be the hudson.model.User.get() does return null on an unknown or null username? (I didn't test the snapshot yet.)

Code changed in jenkins
User: Michael Clarke
Path:
src/main/java/hudson/scm/CVSChangeLogSet.java
http://jenkins-ci.org/commit/cvs-plugin/39502b660f745d04bd608a40cfb6517d5ea716fc
Log:
JENKINS-20192 don't attempt to build user during internal comparison

Simon: nice guess, but not right. User will return null if the provided username is null (although will create a user when an unknown username is provided), but that's not the issue we're seeing.

I've made a change to compare usernames rather than whole users (since these can't be built on slaves in never Jenkins versions) during changelog generation which is now available in the latest snapshot (https://jenkins.ci.cloudbees.com/job/plugins/job/cvs-plugin/201/org.jenkins-ci.plugins$cvs/artifact/org.jenkins-ci.plugins/cvs/2.11-SNAPSHOT/cvs-2.11-SNAPSHOT.hpi). Could one of you try that.

I am Sorry. This evening, it is not possible for me to test the snapshot. (My team members need Jenkins.) May be I can test it tomorrow afternoon/evening (GMT+2).

The CVS Plugin 2.11-SNAPSHOT (private-10/23/2013 13:33-jenkins) from Build #202 seems to work for me.

Agreed, snapshot from build #202 is a go!