Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17965

CVS updates not working correctly after upgrading CVS plugin from v1.6 to 2.8

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I upgraded to CVS plugin version 2.8 from 1.6, and also ran the 'Manage Old Data' process from the Manage Jenkins screen.

      After the update, some projects were not retrieving changes that were committed to CVS and putting them into the workspace. If I clicked on the 'Recent Changes' link in Jenkins for the job, the changes would appear there, but they were not being pulled into the workspace and CVS polling log showed 'no changes'.

      For some projects this was not an issue, but for other projects it was. I checked the config files, and some had been updated to the 2.8 format and some still had the 1.6 format. The jobs that had been updated to the 2.8 format were the ones that were not pulling newly committed files into the workspace.

      It looks like the bug occurs when the config files use the 2.8 plugin format and the 'Use Update' option is selected (<canUseUpdate>true</canUseUpdate>). I deselected this option, and also selected 'Force clean copy for locally modified files' (<cleanOnFailedUpdate>true</cleanOnFailedUpdate>). The files then began to be correctly updated in the workspace.

      Here is a config file example where the 1.6 plugin format is used (and continues working with the 2.8 plugin installed):
      <scm class="hudson.scm.CVSSCM" plugin="cvs@1.6">
      <cvsroot>:pserver:user@server.com:/cvsroot/stuff</cvsroot>
      <module>ExModule</module>
      <canUseUpdate>true</canUseUpdate>
      <useHeadIfNotFound>false</useHeadIfNotFound>
      <flatten>false</flatten>
      <isTag>false</isTag>
      <excludedRegions></excludedRegions>
      </scm>

      And here is a config file example where the 2.8 plugin format is used and the files do not get updated when there is a commit to CVS:
      <scm class="hudson.scm.CVSSCM" plugin="cvs@2.8">
      <flatten>true</flatten>
      <repositories>
      <hudson.scm.CvsRepository>
      <cvsRoot>:pserver:user@server.com:/cvsroot/stuff</cvsRoot>
      <repositoryItems>
      <hudson.scm.CvsRepositoryItem>
      <modules>
      <hudson.scm.CvsModule>
      <localName></localName>
      <remoteName>ExJob2</remoteName>
      </hudson.scm.CvsModule>
      </modules>
      <location class="hudson.scm.CvsRepositoryLocation$HeadRepositoryLocation">
      <locationType>HEAD</locationType>
      <useHeadIfNotFound>false</useHeadIfNotFound>
      </location>
      </hudson.scm.CvsRepositoryItem>
      </repositoryItems>
      <compressionLevel>-1</compressionLevel>
      <excludedRegions>
      <hudson.scm.ExcludedRegion>
      <pattern></pattern>
      </hudson.scm.ExcludedRegion>
      </excludedRegions>
      <password>iLig231CAGwVtdt2/P6vseSiX+rCNjWwXG4/sAyjj1c=</password>
      <passwordRequired>true</passwordRequired>
      </hudson.scm.CvsRepository>
      </repositories>
      <canUseUpdate>true</canUseUpdate>
      <skipChangeLog>false</skipChangeLog>
      <pruneEmptyDirectories>true</pruneEmptyDirectories>
      <disableCvsQuiet>true</disableCvsQuiet>
      <cleanOnFailedUpdate>false</cleanOnFailedUpdate>
      <forceCleanCopy>true</forceCleanCopy>
      </scm>

      after changing to these values in the 2.8 plugin format:
      <canUseUpdate>false</canUseUpdate>
      <cleanOnFailedUpdate>true</cleanOnFailedUpdate>

      it appeared to start working again. I think it was because of the canUseUpdate flag.

        Attachments

          Activity

          Hide
          belpk K P added a comment -

          So it looks like your files aren't updated when the "use update" (-C) flag is set, though the changelog sees the changes?

          Looks the same issue as the one we're having in JENKINS-17383 which essentially means that option -C doesn't work.

          Show
          belpk K P added a comment - So it looks like your files aren't updated when the "use update" (-C) flag is set, though the changelog sees the changes? Looks the same issue as the one we're having in JENKINS-17383 which essentially means that option -C doesn't work.
          Hide
          joel1234567 Joel Wheeler added a comment - - edited

          Yes, exactly- the files arent updated when "use updated" flag is set, tho the changelog sees the changes.

          Show
          joel1234567 Joel Wheeler added a comment - - edited Yes, exactly- the files arent updated when "use updated" flag is set, tho the changelog sees the changes.
          Hide
          joel1234567 Joel Wheeler added a comment -

          Just read thru your bug post. If I am remembering the situation correctly, I think one difference between our two issues are that my polling logs show "No changes detected" when it polls CVS- so mine never even attempts the update. Your logs show that the a change is detected but the update is not updating.

          Show
          joel1234567 Joel Wheeler added a comment - Just read thru your bug post. If I am remembering the situation correctly, I think one difference between our two issues are that my polling logs show "No changes detected" when it polls CVS- so mine never even attempts the update. Your logs show that the a change is detected but the update is not updating.
          Hide
          saschavogt Sascha Vogt added a comment -

          For us it seemed that using the forceCleanCopy flag resulted in sticky checkouts (have a look into the workspace, are there files with a # and version numbers in the name?) Wiping the workspace and disabling the flag helped...

          Show
          saschavogt Sascha Vogt added a comment - For us it seemed that using the forceCleanCopy flag resulted in sticky checkouts (have a look into the workspace, are there files with a # and version numbers in the name?) Wiping the workspace and disabling the flag helped...
          Hide
          arysin Andriy Rysin added a comment -

          We also observed some failures in updating from cvs properly when forceCleanCopy and canUseUpdate are true.

          Show
          arysin Andriy Rysin added a comment - We also observed some failures in updating from cvs properly when forceCleanCopy and canUseUpdate are true.
          Hide
          cscooper Chris Shearer Cooper added a comment -

          I ran into a problem with the CVS plugin, Michael Clarke asked me to add the details here.

          Symptoms:
          We have a matrix job that runs fine except that when the master does
          that initial CVS update on the master prior to launching any of the matrix
          builds on slaves, it gives a CVS "file was lost" error for every file in the
          project.

          The job is parameterized with a boolean named DELETE_WORKSPACE which is
          set as the "Check parameter" for "Delete workspace before build starts" in
          the Build Environment. If I set DELETE_WORKSPACE to true, the build runs
          perfectly without any CVS errors which implies that my CVS authentication is
          correct.

          I tried running the CVS commands from the terminal window, and here's
          what I see.

          If I run the commands directly:
          1) cvs checkout -P -d project project (this is what Jenkins does if DELETE_WORKSPACE is true)
          2) cvs update -C -d -P project (this is what Jenkins does if DELETE_WORKSPACE is false)
          Both CVS commands run fine.

          If I let Jenkins run the first command by performing the build:
          1) Run the Jenkins job with DELETE_WORKSPACE=true
          2) cvs update -C -d -P project
          During the cvs update, CVS gives me a bunch of warnings about locally modified files being moved to temporary files.

          And if I do this:
          1) Run the Jenkins job with DELETE_WORKSPACE=true
          2) cvs status project
          3) cvs update -C -d -P project
          Then I don't get any warnings during the cvs update about locally modified files.

          We are running Jenkins 1.534 with the Jenkins CVS Plug-in version 2.9 on OSX 10.7.5 with CVS version 1.12.13

          Michael suspects "something is going wrong with the way we manage the entries file."

          Show
          cscooper Chris Shearer Cooper added a comment - I ran into a problem with the CVS plugin, Michael Clarke asked me to add the details here. Symptoms: We have a matrix job that runs fine except that when the master does that initial CVS update on the master prior to launching any of the matrix builds on slaves, it gives a CVS "file was lost" error for every file in the project. The job is parameterized with a boolean named DELETE_WORKSPACE which is set as the "Check parameter" for "Delete workspace before build starts" in the Build Environment. If I set DELETE_WORKSPACE to true, the build runs perfectly without any CVS errors which implies that my CVS authentication is correct. I tried running the CVS commands from the terminal window, and here's what I see. If I run the commands directly: 1) cvs checkout -P -d project project (this is what Jenkins does if DELETE_WORKSPACE is true) 2) cvs update -C -d -P project (this is what Jenkins does if DELETE_WORKSPACE is false) Both CVS commands run fine. If I let Jenkins run the first command by performing the build: 1) Run the Jenkins job with DELETE_WORKSPACE=true 2) cvs update -C -d -P project During the cvs update, CVS gives me a bunch of warnings about locally modified files being moved to temporary files. And if I do this: 1) Run the Jenkins job with DELETE_WORKSPACE=true 2) cvs status project 3) cvs update -C -d -P project Then I don't get any warnings during the cvs update about locally modified files. We are running Jenkins 1.534 with the Jenkins CVS Plug-in version 2.9 on OSX 10.7.5 with CVS version 1.12.13 Michael suspects "something is going wrong with the way we manage the entries file."
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Michael Clarke
          Path:
          src/main/java/org/netbeans/lib/cvsclient/response/ModTimeResponse.java
          http://jenkins-ci.org/commit/cvsclient/8432f1431829bb75ab305eec5b72da804e91272b
          Log:
          [FIXED JENKINS-17965 JENKINS-17383] parse timezone in server response

          Compare: https://github.com/jenkinsci/cvsclient/compare/3003bc92180c...8432f1431829

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Michael Clarke Path: src/main/java/org/netbeans/lib/cvsclient/response/ModTimeResponse.java http://jenkins-ci.org/commit/cvsclient/8432f1431829bb75ab305eec5b72da804e91272b Log: [FIXED JENKINS-17965 JENKINS-17383] parse timezone in server response Compare: https://github.com/jenkinsci/cvsclient/compare/3003bc92180c...8432f1431829
          Hide
          mc1arke Michael Clarke added a comment -

          Fixed in v2.10 of the plugin

          Show
          mc1arke Michael Clarke added a comment - Fixed in v2.10 of the plugin

            People

            • Assignee:
              mc1arke Michael Clarke
              Reporter:
              joel1234567 Joel Wheeler
            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: