管道中合并请求目标分支和源分支之间的 Gitlab 差异

Question

我的用途包括查找 MR 将设置的合并请求和主分支或发布分支（我想要比较的分支）之间的差异CI_MERGE_REQUEST_TARGET_BRANCH。

CHANGED_DIRS=$(git diff --name-only ${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}...${CI_COMMIT_REF_NAME} | xargs -L1 dirname | uniq | cut -d'/' -f1 |tail -n+2 | uniq)

但 gitlab 似乎无法识别合并请求目标分支差异并给出此输出。

fatal: ambiguous argument 'master...source': unknown revision or path not in the working tree.

如何找到差异（目录）。感谢帮助！

Answer 1

正如有人已经提到的，这是因为 GitLab-CI 进行浅克隆而不是完整克隆。然而，我没有设计一种方法来进行完整克隆或使用远程比较，而是使用 GitLab-CI 中的内置变量：CI_MERGE_REQUEST_DIFF_BASE_SHA。

要获取文件，请使用： git diff --name-only ${CI_MERGE_REQUEST_DIFF_BASE_SHA}

CI_MERGE_REQUEST_DIFF_BASE_SHA - 合并请求差异的基本 SHA。参考号

Answer 2

我通过更改命令解决了这个错误

git diff --name-only ${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}...${CI_COMMIT_REF_NAME}

到

git diff --name-only remotes/origin/${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}...remotes/origin/${CI_COMMIT_REF_NAME}。

看来 gitlab runner 没有任何本地分支机构。所以我们必须告诉它比较远程分支之间的差异。

Answer 3

这并不是真正的Git问题，而是 GitLab-CI 问题。然而，这些特殊问题在多个 CI/CD 系统中突然出现，总是出于相同的一般原因：

• 对大型存储库进行完整克隆的速度很慢。
• CI 系统通常从克隆存储库开始。
• 因此，CI 系统通常首先对存储库进行不完整的克隆。
• Git 过去只提供了两种方法来做到这一点：¹ 浅克隆和单分支克隆。事实上，它们往往会结合在一起：使用 进行浅克隆，也会生成单分支克隆，除非您也通过添加来强制覆盖 Git 的默认设置。git clone --depth number--no-single-branch

现在，任何给定 CI/CD 系统中的克隆命令都可以是可控的，或者可以在提供开发人员可用的任何软件旋钮之前由CI/CD 系统完成。如果您可以影响该命令，那么通常就是可行的方法，但如果不能，您仍然可以通过运行其他 Git 命令来纠正问题（这又取决于 CI/CD 系统）：

• git remote set-branches --add允许您将各种分支添加到其他单分支克隆中；
• git fetch --depth number、、 和是改变现有浅层克隆深度或完全消除深度限制的三种方法。git fetch --deepen numbergit fetch --unshallow

如果您的 CI/CD 系统进行浅层单分支克隆，并且您需要具有更多远程跟踪名称的更深克隆，则可以使用git remote和/或 来获得git fetch。

由于我没有使用过 GitLab 的 CI 系统，所以我无法在这里提供配方，但根据评论，听起来他们--depth 50默认使用。如果您有深度旋钮，则将其设置为零 ( 0) 是禁用该参数的常用方法--depth，这也会禁用单分支性。

请注意，无论系统如何克隆您的存储库，当通过标签克隆时，您通常只有一个分支名称，甚至可能没有（分离的 HEAD）。完整克隆将具有一整套远程跟踪名称，而单分支克隆将只有一个远程跟踪名称，直到您使用git remote调整它并运行后续命令git fetch来添加更多远程跟踪名称。

使用 GitHub Actions，v2签出默认情况下会进行浅单分支克隆，而v1签出会进行完整克隆。

¹现在有第三种方法，即所谓的带有承诺遥控器的部分克隆。这可以说是 CI 系统实现这一目标的正确方法，但由于多种原因，部分克隆还不是很好，因此这可能需要等待实现的改进。