• Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Blocker Blocker
    • cvs-plugin
    • None
    • Windows Server 2008 R2 Standard
      CVS plugin version 1.6
      Tortoise CVS

      We have a lot of legacy projects that are stored in CVS. We use Windows in house and SSPI to authenticate. I am almost able to get a working setup with Jenkins but I have one missing piece - checking out from cvs.

      Conceptually our setup:
      CVS Module structure:
      /ThirdParty/...
      /Applications/...
      /Libraries/lib1/
      /Libraries/lib2/

      I cannot use the current CVS plugin because it doesn't support SSPI, so I downgraded to version 1.6. With this version I use the legacy mode to checkout, because I need the directory structure to stay intact. This works and everything checks out, but then it appears to error looking for the changes. There is no CVS folder created at the root of the project structure and that's where it executes the command, so it dies not finding any changes.

      Console log:

      Building in workspace D:\bin\Jenkins\web.subject
      [web.subject] $ cvs -Q -z3 -d :sspi:vsbuild:/sw_development co -P -D "Wednesday, June 26, 2013 8:01:43 PM UTC" Web.SubjectAssessmentForm
      $ computing changelog
      cvs log: in directory .:
      cvs [log aborted]: there is no version here; do 'cvs checkout' first
      ERROR: cvs exited with error code 1
      Command line was [Executing 'cvs' with arguments:
      '-d:sspi:vsbuild:/sw_development'
      'log'
      '-S'
      '-d'
      '>=2013-06-25'
      'Web.SubjectAssessmentForm'
      
      The ' characters around the executable and arguments are
      not part of the command.
      ] in D:\bin\Jenkins\web.subject
      Input text:
      START==>null<==END
      Working directory is D:\bin\Jenkins\web.subject
      cvs exited with error code 1
      Command line was [Executing 'cvs' with arguments:
      '-d:sspi:vsbuild:/sw_development'
      'log'
      '-S'
      '-d'
      '>=2013-06-25'
      'Web.SubjectAssessmentForm'
      
      The ' characters around the executable and arguments are
      not part of the command.
      ] in D:\bin\Jenkins\web.subject
      Input text:
      START==>null<==END
      	at hudson.org.apache.tools.ant.taskdefs.AbstractCvsTask.runCommand(AbstractCvsTask.java:387)
      	at hudson.org.apache.tools.ant.taskdefs.AbstractCvsTask.execute(AbstractCvsTask.java:457)
      	at hudson.org.apache.tools.ant.taskdefs.cvslib.ChangeLogTask.execute(ChangeLogTask.java:293)
      	at hudson.scm.CVSSCM$4.invoke(CVSSCM.java:967)
      	at hudson.scm.CVSSCM$4.invoke(CVSSCM.java:887)
      	at hudson.FilePath.act(FilePath.java:905)
      	at hudson.FilePath.act(FilePath.java:878)
      	at hudson.scm.CVSSCM.calcChangeLog(CVSSCM.java:887)
      	at hudson.scm.CVSSCM.checkout(CVSSCM.java:429)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1369)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581)
      	at hudson.model.Run.execute(Run.java:1593)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:242)
      Finished: FAILURE

          [JENKINS-18522] Cannot check out CVS module using legacy mode

          John McCabe added a comment -

          @Scott,

          This may be specific to my project, but I'm using a custom workspace for my project (E:\Work\Jenkins\<ModuleName>) and have left the "Legacy mode" checkbox unchecked and this seems to work for me.

          @Michael

          You mention branching 1.6 and applying retrospective changes but there is another option.

          The reason both Scott and I have been forced into messing around with version 1.6 of the plug-in is described in https://issues.jenkins-ci.org/browse/JENKINS-18330; basically the current version doesn't support :sspi:, and doesn't provide a mechanism to use an external program to implement the :ext: protocol in the way that Netbeans itself does. It seems to only support :ext: using the built-in facilities (SSH) of the Netbeans-like client.

          A better option for me (and I suspect Scott and the few others who've been struggling with this issue on the Jenkins forum) would be to modify the current CVS plug-in to allow an option to use either the built-in facilities or an external program. Given that 1.6 forced the use of an external program I would assume that, once the output from the CVS commands (either from within the plug-in or from the external program) is captured then the processing would be fairly common.

          I imagine this would be a much simpler option than branching 1.6 and having separate versions of the plug-in.

          Does this sound feasible?

          John

          John McCabe added a comment - @Scott, This may be specific to my project, but I'm using a custom workspace for my project (E:\Work\Jenkins\<ModuleName>) and have left the "Legacy mode" checkbox unchecked and this seems to work for me. @Michael You mention branching 1.6 and applying retrospective changes but there is another option. The reason both Scott and I have been forced into messing around with version 1.6 of the plug-in is described in https://issues.jenkins-ci.org/browse/JENKINS-18330 ; basically the current version doesn't support :sspi:, and doesn't provide a mechanism to use an external program to implement the :ext: protocol in the way that Netbeans itself does. It seems to only support :ext: using the built-in facilities (SSH) of the Netbeans-like client. A better option for me (and I suspect Scott and the few others who've been struggling with this issue on the Jenkins forum) would be to modify the current CVS plug-in to allow an option to use either the built-in facilities or an external program. Given that 1.6 forced the use of an external program I would assume that, once the output from the CVS commands (either from within the plug-in or from the external program) is captured then the processing would be fairly common. I imagine this would be a much simpler option than branching 1.6 and having separate versions of the plug-in. Does this sound feasible? John

          This does sound (and is) feasible. We currently do it for the Git plugin and, whilst the CVS client doesn't play as nicely as the Git client, we should be able to use a similar calling mechanism to how 1.6 worked, but with the rest of the 2.X features working as they were.

          I'll do a bit more digging and post a snapshot once I have one (I don't use SSPI so can't prove if this works or not)

          Michael Clarke added a comment - This does sound (and is) feasible. We currently do it for the Git plugin and, whilst the CVS client doesn't play as nicely as the Git client, we should be able to use a similar calling mechanism to how 1.6 worked, but with the rest of the 2.X features working as they were. I'll do a bit more digging and post a snapshot once I have one (I don't use SSPI so can't prove if this works or not)

          Scott Telle added a comment -

          @John
          thanks for suggesting that solution.

          @Michael
          I have looked at the code for the plugin and see where the potential problem is. Our CVS modules don't map to directory names, the cvs log command expects the directory to get logging info from, not the module. The code (at least in 1.6) uses the module name to log and in my case errors out.

          ... (line 960 [CVSSCM.java version 1.6|https://github.com/jenkinsci/cvs-plugin/blob/cvs-1.6/src/main/java/hudson/scm/CVSSCM.java]) 
                             } else {
                                  // fallback
                                  if(!flatten)
                                      task.setPackage(getAllModulesNormalized());
                              }
          

          Scott Telle added a comment - @John thanks for suggesting that solution. @Michael I have looked at the code for the plugin and see where the potential problem is. Our CVS modules don't map to directory names, the cvs log command expects the directory to get logging info from, not the module. The code (at least in 1.6) uses the module name to log and in my case errors out. ... (line 960 [CVSSCM.java version 1.6|https: //github.com/jenkinsci/cvs-plugin/blob/cvs-1.6/src/main/java/hudson/scm/CVSSCM.java]) } else { // fallback if (!flatten) task.setPackage(getAllModulesNormalized()); }

          John McCabe added a comment -

          That would be very useful and I would be happy to give it a go.

          One of the things I mentioned on the other ticket is that I've got a load of jobs that, now that I've downdated to the 1.6 version of the plugin, won't even load. It would be nice to be able to update to 2.9+ and get them at least loaded so that I can reconfigure them (although I'm not sure if that's feasible!)

          Many thanks for your time.
          John

          John McCabe added a comment - That would be very useful and I would be happy to give it a go. One of the things I mentioned on the other ticket is that I've got a load of jobs that, now that I've downdated to the 1.6 version of the plugin, won't even load. It would be nice to be able to update to 2.9+ and get them at least loaded so that I can reconfigure them (although I'm not sure if that's feasible!) Many thanks for your time. John

          Scott Telle added a comment -

          As for my issue, I think it's resolved... I still agree with John regarding an option to use an external .exe, but that's probably better covered in the other issue.

          My resolution for anyone else:

          I was using aliases in the CVSROOT\modules file that was creating a directory structure like so:

          # CVSROOT\modules
          My.Application -a Applications/bin Applications/MyApplication Libraries/Library1 Libraries/Library2
          
          # Result:
          Applications/
            bin/
            MyApplication/
          Libraries/
            Library1/
            Library2/
          

          This can be reproduced by just adding each of the aliases above into the modules box in Jenkins. This is actually simpler to set up - versus creating a module that handled this for us.

          Scott Telle added a comment - As for my issue, I think it's resolved... I still agree with John regarding an option to use an external .exe, but that's probably better covered in the other issue. My resolution for anyone else: I was using aliases in the CVSROOT\modules file that was creating a directory structure like so: # CVSROOT\modules My.Application -a Applications/bin Applications/MyApplication Libraries/Library1 Libraries/Library2 # Result: Applications/ bin/ MyApplication/ Libraries/ Library1/ Library2/ This can be reproduced by just adding each of the aliases above into the modules box in Jenkins. This is actually simpler to set up - versus creating a module that handled this for us.

          John McCabe added a comment -

          @Scott

          You say your issue is resolved but I just wanted to be clear; the issue you found whilst downgrading to version 1.6 of the CVS plug-in is resolved, but it doesn't get round the issue that it's impossible to us SSPI protocol with the most up-to-date version of the CVS and you're forced to use a version that's no longer supported to achieve this.

          Is that correct

          John

          John McCabe added a comment - @Scott You say your issue is resolved but I just wanted to be clear; the issue you found whilst downgrading to version 1.6 of the CVS plug-in is resolved, but it doesn't get round the issue that it's impossible to us SSPI protocol with the most up-to-date version of the CVS and you're forced to use a version that's no longer supported to achieve this. Is that correct John

          Scott Telle added a comment -

          That is correct!

          I figured that your open JIRA issue encapsulated that problem better though. I created this issue, because I was having trouble with version 1.6 of the plugin, which I was able to work around in a satisfactory manner.

          Thanks John!

          Scott Telle added a comment - That is correct! I figured that your open JIRA issue encapsulated that problem better though. I created this issue, because I was having trouble with version 1.6 of the plugin, which I was able to work around in a satisfactory manner. Thanks John!

          John McCabe added a comment -

          Thanks Scott,

          I had just wanted to clarify on the basis that there is still a problem going forward (i.e. as described in https://issues.jenkins-ci.org/browse/JENKINS-18330) and that your eventual success was related to a rather nasty workaround of using an unsupported version of the plugin.

          John

          John McCabe added a comment - Thanks Scott, I had just wanted to clarify on the basis that there is still a problem going forward (i.e. as described in https://issues.jenkins-ci.org/browse/JENKINS-18330 ) and that your eventual success was related to a rather nasty workaround of using an unsupported version of the plugin. John

          John McCabe added a comment -

          Michael,

          Just wondered if you'd had any chance to look at this problem (well, the problem I mentioned here https://issues.jenkins-ci.org/browse/JENKINS-18330 which is more related to the discussion on 18522).

          Many thanks
          John

          John McCabe added a comment - Michael, Just wondered if you'd had any chance to look at this problem (well, the problem I mentioned here https://issues.jenkins-ci.org/browse/JENKINS-18330 which is more related to the discussion on 18522). Many thanks John

          Not fixing the CVS 1.6 issue since this version of the plugin is no longer supported (the latest LTS version of Jenkins uses a new version of the plugin). The outstanding problem causing the user to need 1.6 is now being tracked under the relevant issue number.

          Michael Clarke added a comment - Not fixing the CVS 1.6 issue since this version of the plugin is no longer supported (the latest LTS version of Jenkins uses a new version of the plugin). The outstanding problem causing the user to need 1.6 is now being tracked under the relevant issue number.

            mc1arke Michael Clarke
            srtelle Scott Telle
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: