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

CVS Plugin update adjusts version but not timestamp in CVS/Entries

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: cvs-plugin
    • Labels:
    • Environment:
      CentOS 6.4, Jenkins 1.532.2, CVS Plugin 2.11
    • Similar Issues:

      Description

      Intermittent issue where a cvs triggered build fails to update the static custom workspace properly. A commit went into CVS at Fri Apr 25 14:49:03 2014 UTC, the build was triggered at Apr 25, 2014 7:50:10 AM PDT (less than a minute later). The CVS update modified the CVS/Entries file with the new revision but left the old timestamp. The contents of the file remained the old version, but running manual cvs status claims the file is up-to-date and on the new revision. File is proven to be not updated and has the contents of the old revision. CVS can be corrected by adjusting CVS/Entries revision back to it's true value. Then when I manually update the file, the changes are incorporated and the CVS/Entries file is left correct.

      This has occurred just twice in the last month or so, but make Jenkins unsuitable since it corrupts the workspace and reports invalid build breakages.

      (redacted)

      XXXXX/xxxxx > cvs status xxxxxx.h
      ===================================================================
      File: xxxxxx.h Status: Up-to-date

      Working revision: 1.132.2.1
      Repository revision: 1.132.2.1 XXX/xxxxxx.h,v
      Sticky Tag: BRANCH (branch: 1.132.2)
      Sticky Date: (none)
      Sticky Options: (none)

      CVS status is apparently not checking the contents of the file.

      Here we see the truth about the file
      > grep \$Id xxxxxx.h

      • $Id: xxxxxx.h,v 1.132 2013/11/26 20:23:34 sssssssss Exp $
        /

      And other tests prove the local file is unchanged.

      Below, a diff of CVS/Enties. The top one is from a fresh checkout of the branch and the bottom is our corrupt Jenkins workspace

      < /xxxxxxx.h/1.132.2.1/Fri Apr 25 14:49:03 2014//TBRANCH

      > /xxxxxxx.h/1.132.2.1/Tue Nov 26 20:23:34 2013//TBRANCH

        Attachments

          Activity

          Hide
          elmoz Mark Ruedy added a comment - - edited

          This doesn't explain why the CVS Plugin would get the file into this state, but one suggestion is that the client CVS command does not check further if the CVS/Entries timestamp matches the timstamp on the file itself. That may explain why cvs command like status, update, diff are confused about the file.

          Show
          elmoz Mark Ruedy added a comment - - edited This doesn't explain why the CVS Plugin would get the file into this state, but one suggestion is that the client CVS command does not check further if the CVS/Entries timestamp matches the timstamp on the file itself. That may explain why cvs command like status, update, diff are confused about the file.
          Hide
          elmoz Mark Ruedy added a comment -

          I can't use Jenkins because of this.

          Show
          elmoz Mark Ruedy added a comment - I can't use Jenkins because of this.
          Hide
          mc1arke Michael Clarke added a comment -

          Reducing priority since only one user has reported issue, and can be worked around by setting workspace to wipe-out on each build if issue does occur.

          Show
          mc1arke Michael Clarke added a comment - Reducing priority since only one user has reported issue, and can be worked around by setting workspace to wipe-out on each build if issue does occur.

            People

            • Assignee:
              Unassigned
              Reporter:
              elmoz Mark Ruedy
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: