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

"Another git process seems to be running in this repository" when Jenkins is the only thing using workspaces

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • git-client-plugin
    • None
    • Jenkins 2.86, Git Plugin 3.6.0, Git Client Plugin 2.5.0

      Some builds spuriously fail with the following error message:

      stderr: fatal: Unable to create 'h:/hudson/pipeline-github/core/.git/index.lock': File exists.
      
      Another git process seems to be running in this repository, e.g.
      an editor opened by 'git commit'. Please make sure all processes
      are terminated then try again. If it still fails, a git process
      may have crashed in this repository earlier:
      remove the file manually to continue.
      

      I think that there are only a few obvious possibilities here:

      1. Jenkins is trying to use the same workspace twice at the same time, which would be a bug on Jenkins' part.
      2. Some earlier operation crashed, and Jenkins should be automatically deleting the lock for us, because expecting the user to do this isn't really reasonable for a supposedly automated build system.
      3. Some user was diddling with the workspace and deserves to have their lock broken, in which case refer to #2.

          [JENKINS-47652] "Another git process seems to be running in this repository" when Jenkins is the only thing using workspaces

          trejkaz added a comment -

          Commands leading up to the error are a bit confusing...

          [macosx]  > git rev-parse --is-inside-work-tree # timeout=10
          [macosx]  > git config remote.origin.url git@github.eng.nuix.com:Nuix/core.git # timeout=10
          [macosx]  > git --version # timeout=10
          [macosx]  > git fetch --tags --progress git@github.eng.nuix.com:Nuix/core.git +refs/pull/50/head:refs/remotes/origin/PR-50 +refs/heads/master:refs/remotes/origin/master --prune # timeout=40
          [macosx]  > git config core.sparsecheckout # timeout=10
          [macosx]  > git checkout -f 72d57d4d7854d9b2b9eb78e0fe158869b3f04f80 # timeout=30
          [macosx]  > git merge 0abbc94cdff38bfe76dad45562011f6f703143ce # timeout=10
          [macosx]  > git config core.sparsecheckout # timeout=10
          [macosx]  > git checkout -f 72d57d4d7854d9b2b9eb78e0fe158869b3f04f80 # timeout=30
          

          First question is, why is it running git checkout on the same hash twice? Second question is, why didn't the first one remove the lock after it succeeded?

          trejkaz added a comment - Commands leading up to the error are a bit confusing... [macosx] > git rev-parse --is-inside-work-tree # timeout=10 [macosx] > git config remote.origin.url git@github.eng.nuix.com:Nuix/core.git # timeout=10 [macosx] > git --version # timeout=10 [macosx] > git fetch --tags --progress git@github.eng.nuix.com:Nuix/core.git +refs/pull/50/head:refs/remotes/origin/PR-50 +refs/heads/master:refs/remotes/origin/master --prune # timeout=40 [macosx] > git config core.sparsecheckout # timeout=10 [macosx] > git checkout -f 72d57d4d7854d9b2b9eb78e0fe158869b3f04f80 # timeout=30 [macosx] > git merge 0abbc94cdff38bfe76dad45562011f6f703143ce # timeout=10 [macosx] > git config core.sparsecheckout # timeout=10 [macosx] > git checkout -f 72d57d4d7854d9b2b9eb78e0fe158869b3f04f80 # timeout=30 First question is, why is it running git checkout on the same hash twice? Second question is, why didn't the first one remove the lock after it succeeded?

          Jon B added a comment -

          I just hit this bug.

          Our jenkins uses some groovy scripting to kill off jobs in flight when new commits come in so as to save resources.

          So it seems that our script to try to stop the duplicate pipeline might have left git in a bad state.

          What's the best way to gracefully stop the pipeline? We use lots of tricks but it's not clear the 'best' way to force a pipeline to really stop - usually our attempts just cause an "are you sure" message to pop into the console out.

          Jon B added a comment - I just hit this bug. Our jenkins uses some groovy scripting to kill off jobs in flight when new commits come in so as to save resources. So it seems that our script to try to stop the duplicate pipeline might have left git in a bad state. What's the best way to gracefully stop the pipeline? We use lots of tricks but it's not clear the 'best' way to force a pipeline to really stop - usually our attempts just cause an "are you sure" message to pop into the console out.

          James Nord added a comment -

          > What's the best way to gracefully stop the pipeline

          `properties([disableConcurrentBuilds(abortPrevious: true)])`

          James Nord added a comment - > What's the best way to gracefully stop the pipeline `properties( [disableConcurrentBuilds(abortPrevious: true)] )`

            Unassigned Unassigned
            trejkaz trejkaz
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: