checkout@v2 unable to write pack file

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

[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]

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