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

JGit file contents are not reset like CLI git file contents when a job runs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.566
      git plugin 2.2.1
      git client plugin 1.9.1
      JGit
      Tomcat 7
      Java 1.7.0_60
      RHEL6
      gitblit Repos / http
    • Similar Issues:

      Description

      JGit implementation does not reset existing tracked files (modified by a previous build)at the start of each job. Command line git implementation does reset existing tracked files modified by a previous build.

      The git fetch works, moreover the correct commit hashcode is used (visible in console log).

      A manual (commandline!) "git reset --hard" updates the working dir.
      Our workaround: Force delete jenkins working dir.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          I can duplicate this bug. Thanks for the bug report.

          The command line git implementation in the git client plugin performs a force checkout of the files associated with the SHA1 being built. That causes changes to tracked files to be discarded from one build to the next.

          The JGit implementation in the git client plugin seems to not perform a force checkout of the files associated with the SHA1 being built. If there are changes in a tracked file, a new build with the JGit implementation leaves the modified file, rather than overwriting it with the version in the repository.

          I duplicated your report by creating a job which performs a checkout, then appends text to one of the tracked files. Each time I run the job using the command line git implementation, it correctly resets the workspace to the state of the git repository, then appends a single line to the tracked file and completes successfully. If the repository were not being reset, the append would have caused those lines to accumulate, but there is always only one line visible at the end of the file.

          Each time I run the job with the JGit implementation, the workspace is not reset and the new content to be added is appended to the target file.

          One work around is to switch to the command line git implementation.

          Does my description match the bug you're seeing, or is the bug I've detected something different than your problem?

          Show
          markewaite Mark Waite added a comment - - edited I can duplicate this bug. Thanks for the bug report. The command line git implementation in the git client plugin performs a force checkout of the files associated with the SHA1 being built. That causes changes to tracked files to be discarded from one build to the next. The JGit implementation in the git client plugin seems to not perform a force checkout of the files associated with the SHA1 being built. If there are changes in a tracked file, a new build with the JGit implementation leaves the modified file, rather than overwriting it with the version in the repository. I duplicated your report by creating a job which performs a checkout, then appends text to one of the tracked files. Each time I run the job using the command line git implementation, it correctly resets the workspace to the state of the git repository, then appends a single line to the tracked file and completes successfully. If the repository were not being reset, the append would have caused those lines to accumulate, but there is always only one line visible at the end of the file. Each time I run the job with the JGit implementation, the workspace is not reset and the new content to be added is appended to the target file. One work around is to switch to the command line git implementation. Does my description match the bug you're seeing, or is the bug I've detected something different than your problem?
          Hide
          chrisabit chrisabit added a comment - - edited

          Thanks for the fast reply Your description seems to hit the point.
          I suppose most of the users will use the command line implementation of git, which works. Unfortunately we (company) are stucked with jGit.
          Our workaround is to clean the working directory and to perform a full clone. This will be sufficient 'til the bug is fixed
          (Spooky ticket id by the way - don't panic and keep the towel dry)

          Show
          chrisabit chrisabit added a comment - - edited Thanks for the fast reply Your description seems to hit the point. I suppose most of the users will use the command line implementation of git, which works. Unfortunately we (company) are stucked with jGit. Our workaround is to clean the working directory and to perform a full clone. This will be sufficient 'til the bug is fixed (Spooky ticket id by the way - don't panic and keep the towel dry)
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java
          http://jenkins-ci.org/commit/git-client-plugin/48fe77daa9c05ddcff4c57f2c163c800028ad955
          Log:
          Test to confirm JENKINS-23424 is a bug in our JGit implementation

          JENKINS-23424 reports that a tracked file which is locally modified is
          not reset to its original content on the next checkout when using our
          JGit implementation. It is reset to its original content when using
          our command line git implementation.

          Compare: https://github.com/jenkinsci/git-client-plugin/compare/0cddb10d5066...48fe77daa9c0

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java http://jenkins-ci.org/commit/git-client-plugin/48fe77daa9c05ddcff4c57f2c163c800028ad955 Log: Test to confirm JENKINS-23424 is a bug in our JGit implementation JENKINS-23424 reports that a tracked file which is locally modified is not reset to its original content on the next checkout when using our JGit implementation. It is reset to its original content when using our command line git implementation. Compare: https://github.com/jenkinsci/git-client-plugin/compare/0cddb10d5066...48fe77daa9c0
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java
          http://jenkins-ci.org/commit/git-client-plugin/fffa4c78fde695165704465af3ebe5c1652395c0
          Log:
          Confirm that JGit 3.4.1 [Fixed JENKINS-23424]

          Prior to JGit 3.4.1, tracked files which were locally modified were
          not reset to their unmodified state by JGit checkout, while the CliGit
          arguments used in the same cases would reset the locally modified file
          to their unmodified state.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java http://jenkins-ci.org/commit/git-client-plugin/fffa4c78fde695165704465af3ebe5c1652395c0 Log: Confirm that JGit 3.4.1 [Fixed JENKINS-23424] Prior to JGit 3.4.1, tracked files which were locally modified were not reset to their unmodified state by JGit checkout, while the CliGit arguments used in the same cases would reset the locally modified file to their unmodified state.
          Hide
          markewaite Mark Waite added a comment -

          Fixed by update to JGit 3.4.1. Test has been changed to continue checking that the behavior remains the same with future JGit releases.

          Show
          markewaite Mark Waite added a comment - Fixed by update to JGit 3.4.1. Test has been changed to continue checking that the behavior remains the same with future JGit releases.
          Hide
          markewaite Mark Waite added a comment -

          Fix is first available in git-client-plugin 1.9.2, released 16 July 2014

          Show
          markewaite Mark Waite added a comment - Fix is first available in git-client-plugin 1.9.2, released 16 July 2014

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              chrisabit chrisabit
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: