GitLab CI并发作业共享PV易致文件覆盖、索引损坏或死锁，需通过subPath隔离路径、强制clean/reset、禁用共享clone、只读挂载.git、flock加锁及限制runner并发等措施保障一致性。
GitLab CI 流水线在并发执行时，若多个作业共享同一个持久化卷（PV），尤其当该卷挂载为读写模式且未做访问控制，极易出现文件覆盖、索引错乱或进程级死锁——典型表现是 git merge 失败、.git/index 损坏、或 rsync/cp 阻塞超时。根本原因不是 Git 本身不支持并发，而是底层文件系统对元数据操作（如 inode 更新、目录项重命名）缺乏原子协调机制。
隔离作业工作空间：用 subpath 实现物理路径隔离
避免所有作业直接挂载同一 NAS 目录根路径。应通过 StorageClass 的 subPath 机制，为每个作业动态分配独立子目录：
- 在 PVC 中声明
volumeMode: Filesystem并指定subPath: ${CI_JOB_ID}或${CI_PIPELINE_ID}-${CI_JOB_NAME} - 确保 StorageClass 的
volumeBindingMode设为WaitForFirstConsumer，使 PV 绑定延迟到作业调度时，避免预分配冲突 - Git 操作前强制执行
git clean -fdx && git reset --hard，清空非仓库管理的临时文件，防止跨作业残留干扰
禁用共享 Git 索引与工作树状态
Git 的 .git/index 和工作树文件是强状态依赖对象，不可被多进程同时写入。即使挂载路径隔离，若作业复用同一 clone 副本，仍可能因缓存或符号链接引发隐式共享：
git-log-tracker
下载
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
- 禁止在流水线中使用
git clone --shared或--reference指向共享仓库缓存目录 - 每个作业必须从裸仓库（bare repo）完整 clone，或使用
git worktree add创建独立工作树，并显式指定--lock参数防止误删 - 将
.git目录整体挂载为只读卷（readOnly: true），仅允许作业写入工作树文件，禁止修改索引和对象数据库
用文件锁替代轮询等待
当必须跨作业协同（如构建产物上传、版本号生成），避免用 sleep 5 && test -f flag.done 这类竞态逻辑。改用基于文件系统的排他锁：
- 使用
flock -w 30 /shared/lockfile -c "your-command"包裹关键区段，超时自动退出而非死等 - 锁文件需放在与作业无关的专用 PV 上（例如一个仅用于协调的 small-rw PVC），不与代码工作卷混用
- 锁释放后立即
rm -f /shared/lockfile，避免残留导致后续流水线永久阻塞
调整 Runner 执行策略：规避容器级资源争用
即使存储层隔离，Docker/Kubernetes 层的并发也可能触发内核级锁（如 overlayfs 的 upperdir 写锁）：
- 在
config.toml中为对应 runner 设置concurrent = 1，强制单作业串行执行（适用于高一致性要求场景） - 改用
docker+machine或kubernetesexecutor 时，启用privileged = true并挂载/dev/fuse，支持git clone --filter=tree:0减少本地对象写入压力 - 对 Java/Node.js 等语言，关闭构建工具的并行下载（如 Maven 的
-T 1C、npm 的--maxsockets=1），减少临时文件竞争
