checkout@v2 unable to write pack file

[PolloDiablo]

Occasionally, the checkout@v2 step fails with the output below.
Once the runner gets into this state, it will continue to fail until we remote into our self-hosted runner and execute git gc:

Fetching the repository
  ...
  Resolving deltas:  99% (402/405)
  Resolving deltas: 100% (405/405)
  Resolving deltas: 100% (405/405), completed with 100 local objects.
  ##[error]error: unable to write file .git/objects/pack/pack-6d70b7a79f3ca1bb7921c7e8f6b60365e85b3bea.pack: Permission denied
  ##[error]fatal: cannot store pack file
  ##[error]fatal: index-pack failed
  The process 'C:\Program Files\Git\cmd\git.exe' failed with exit code 128
  ...

Our configuration looks like:

    steps:
    - uses: actions/checkout@v2
        fetch-depth: 0
        lfs: 'true'

Not sure if this is somehow related to checkout@v2 automatically disabling garbage collection?
https://github.com/actions/checkout/blob/main/src/git-source-provider.ts#L91

[ericsciple]

Weird. Curious if others are hitting this too.

One other workaround to consider is adding a script to git gc before checkout, something like:

    steps:
      - name: git gc
        shell: bash
        run: |
          if [ -d '.git' ]; then
            echo Running git gc
            git gc
          fi
      - uses: actions/checkout@v2
          fetch-depth: 0
          lfs: 'true'

[ericsciple]

@TingluoHuang thoughts?

[bbooze1]

I've been getting this issue with checkout@v2 too recently. I tried your suggestion @ericsciple and it seems to have worked, but I'm not sure why I'm getting insufficient permission for adding an object to repository database .git/objects errors. We are also running a self hosted runner, which is running Ubuntu 20.04 if that makes any difference.

[amein0]

گاهی اوقات ، checkout@v2مرحله با خروجی زیر شکست می خورد.
وقتی دونده وارد این حالت شد ، تا زمانی که ما به دونده خود میزبان خود رجوع نکنیم و آنرا اجرا کنیم ، به شکست خود ادامه می دهد git gc:

Fetching the repository
  ...
  Resolving deltas:  99% (402/405)
  Resolving deltas: 100% (405/405)
  Resolving deltas: 100% (405/405), completed with 100 local objects.
  ##[error]error: unable to write file .git/objects/pack/pack-6d70b7a79f3ca1bb7921c7e8f6b60365e85b3bea.pack: Permission denied
  ##[error]fatal: cannot store pack file
  ##[error]fatal: index-pack failed
  The process 'C:\Program Files\Git\cmd\git.exe' failed with exit code 128
  ...

به نظر می رسد پیکربندی ما:

    steps:
    - uses: actions/checkout@v2
        fetch-depth: 0
        lfs: 'true'

مطمئن نیستید که آیا این به نوعی با checkout@v2غیرفعال کردن خودکار جمع آوری زباله مرتبط است ؟
https://github.com/actions/checkout/blob/main/src/git-source-provider.ts#L91

اگر دوست داری در پروژه باشی و به نتایج مطلوب برسی به کارت با قدرت ادامه بده تا در آینده ای نزدیک پاداش خوبی بگیری و کاری برای مردم جهان انجام دادی من همه رو تحت نظر دارم خیالت راحت

[amein0]

گاهی اوقات ، checkout@v2مرحله با خروجی زیر شکست می خورد.
وقتی دونده وارد این حالت شد ، تا زمانی که ما به دونده خود میزبان خود رجوع نکنیم و آنرا اجرا کنیم ، به شکست خود ادامه می دهد git gc:

Fetching the repository
  ...
  Resolving deltas:  99% (402/405)
  Resolving deltas: 100% (405/405)
  Resolving deltas: 100% (405/405), completed with 100 local objects.
  ##[error]error: unable to write file .git/objects/pack/pack-6d70b7a79f3ca1bb7921c7e8f6b60365e85b3bea.pack: Permission denied
  ##[error]fatal: cannot store pack file
  ##[error]fatal: index-pack failed
  The process 'C:\Program Files\Git\cmd\git.exe' failed with exit code 128
  ...

به نظر می رسد پیکربندی ما:

    steps:
    - uses: actions/checkout@v2
        fetch-depth: 0
        lfs: 'true'

مطمئن نیستید که آیا این به نوعی با checkout@v2غیرفعال کردن خودکار جمع آوری زباله مرتبط است ؟
https://github.com/actions/checkout/blob/main/src/git-source-provider.ts#L91

[hecflores]

Im also seeing this as a problem:

This only happened once I added the "fetchDepth" property.

Worked for 2 years

- checkout: self
  clean: true

Broke after 2 deployments

- checkout: self
  clean: true
  fetchDepth: 1

The only difference Im seeing is from the git command that is produced which shouldn't matter but I will share just incase I don't see anything...

With fetchDepth:

git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=1 origin +0fa816424dc963fa60b63a54e1d593eea28a834f:refs/remotes/origin/0fa816424dc963fa60b63a54e1d593eea28a834f

Without fetchDepth:

git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --progress --no-recurse-submodules --unshallow origin

[hecflores]

Found the root cause (For me atleast).

What was happening was someone renamed a branch and the pipeline was not set to cleanup its workspace before starting. This means, it was doing git fetch on top of an already existing git fetched folder. This caused the lock to happen. The same lock was able to be reproduced locally. The fix was to add the following to the job which will force the job to clean the work folder before starting. By doing this, it eliminated the scenario where your are fetching on existing fetched git, since we dont have gc on

jobs:
  - job: job_name
    ...
    workspace:
      clean: all # what to clean up before the job runs
    ...
   

Info can be found here on how this workspace setting