英文:
Gitlab fetch strategy failed with "could not lock config file"
问题
今天，在一个小的提交之后，GitLab CI流水线停止工作了。它总是出现以下错误：
使用 git 深度设置为 20 获取更改时发生错误：
error: 无法锁定配置文件 /builds/path/to/project.tmp/git-template/config：文件已存在
Git、Runner和Server的配置没有更改，这只是一个普通的提交，但出于某种原因它完全破坏了整个项目的流水线。
现在以前有效的提交流水线也不再工作。我尝试通过hard reset和push --force回滚这个提交，但没有帮助。
只有一个Runner用于运行作业，所以我决定将项目分支到同一组并运行它的流水线...结果它可以工作！而且，它可以在问题开始的提交之后工作。但原始项目仍然不工作。
我还清理了Runner的缓存并重新启动了它（使用Docker执行器）。
最后，我看到了GitLab中的git策略设置，并将其设置为git clone（默认为git fetch），哇，流水线可以工作，但当我将其设置回fetch时，同样的错误又出现了。
我在GitLab上找到了关于这个问题的问题，但要么我没有看到解决方案，要么那里没有解决方案。
如果有人有任何想法，我们可以尝试做些什么来使流水线再次与'git fetch`策略一起工作吗？
如果需要额外的信息，请告诉我需要什么 - 我会更新问题
- Gitlab: 16.0.1-ee免费版
- Gitlab runner: 16.0.1
英文:
Today, after a small commit, the gitlab ci pipeline stopped working. It always crashes with an error:
Fetching changes with git depth set to 20...
error: could not lock config file /builds/path/to/project.tmp/git-template/config: File exists
The configuration of the git, runner, server - did not change, it was an ordinary commit, but for some reason it completely broke the pipeline in the entire project.
Now the commit pipelines that worked earlier also don't work. I tried to roll back this commit via hard reset and push --force, but it didn't help.
Only 1 runner is used to run jobs, so I decided to fork the project into the same group and run the pipeline for it... and it works! Moreover, it works with the commit after which the problems began. But the original project still doesn't work.
I also cleaned the runner cache and restarted it (docker executor)
In the end, I saw the git strategy setup in gitlab and put it on git clone (by default git fetch) and wow, the pipeline worked, but when I returned it back to fetch, the same error came out.
I found issues on gitlab with this problem, but either I didn't see a solution, or there is no solution there.
If anyone has any ideas, what can we try to do to make the pipeline work with the 'git fetch` strategy again?
If you need additional information, tell me what - I will update the question
- Gitlab: 16.0.1-ee free
- Gitlab runner: 16.0.1
答案1
得分: 0
看起来在重新启动运行程序的虚拟机后，问题已解决。
导致错误消失的完整操作列表如下：
- 暴露了
git clone策略 - 我启动了流水线 - 某些东西起作用了
- 几个小时后，我重新启动了虚拟机。
- 我启动了流水线 - 某些东西起作用了
- 暴露了
git fetch策略 - 错误已消失，流水线开始工作。
附注
即使在带有运行程序的虚拟机上，我也找到了一个包含配置文件的git模板目录。它位于/var/lib/docker/volumes/runner-XXXX-cache-YYYY/_data/path/to/project.tmp/git-template/config。也许如果删除所有与运行程序相关的必要卷目录，错误也会消失。
英文:
It looks like the problem was solved after restarting the virtual machine with runners.
A complete list of actions that led to the error disappearing:
- Exposed
git clonestrategy - I started the pipeline - something worked
- After a few hours, I rebooted the VM.
- I started the pipeline - something worked
- Exposed
git fetchstrategy - The error has disappeared, the pipeline has started working.
P.s.
Even on the VM with the runner, I found a directory with git-template containing the config file. He was in /var/lib/docker/volumes/runner-XXXX-cache-YYYY/_data/path/to/project.tmp/git-template/config. Perhaps if you delete all the necessary folders with volumes for runners, the error will also go away
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论