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

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.86, Git Plugin 3.6.0, Git Client Plugin 2.5.0
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            trejkaz 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?

            Show
            trejkaz 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?
            Hide
            piratejohnny 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.

            Show
            piratejohnny 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                trejkaz trejkaz
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: