2

我正在为我的公司配置 Jenkins 环境。当我从源代码管理构建存储库时，我们使用 gitea (1.9.3)、Jenkins 2.194 和 git 版本 2.23，它会构建存储库，但执行 fetch 命令需要 120-150 秒。关于做什么的任何建议？

我尝试更改 git 客户端，确保凭据正常，尝试使用空或完整的存储库以及子模块和只有一个分支配置。

有问题的部分：

编辑 1：无论存储库是空的还是充满了东西，构建都需要 4:27，如果我从服务器手动运行 git fetch 命令大约需要 3 秒。

4

3 回答 3

0

我尝试在 Ubuntu 服务器 18.04 上安装 Jenkins，它将使用子模块的完整构建时间从 4.5 分钟缩短到 20 秒左右。

于 2019-09-18T08:19:16.503 回答
0

我尝试在 Ubuntu 服务器 18.04 上安装 Jenkins，它将使用子模块的完整构建时间从 4.5 分钟缩短到 20 秒左右。

在邮件列表中确实报告了 Windows 上超过 2.20 的任何 Git的性能回归。
同样在git-for-windows/git问题 2199中。

使用 Git 2.29（2020 年第四季度），围绕子模块处理的优化将使 Windows 上的速度更快。

请参阅Orgad Shaneh ( ) 的提交 7ea0c2f（2020 年 9 月 4 日）。（由Junio C Hamano 合并 -- --在提交 bcb68bf中，2020 年 9 月 22 日）orgads
gitster

fetch：不要在未更改的 refs 中查找子模块更改

签字人：Orgad Shaneh

当使用子模块递归获取时，对于超级项目中的每个 ref，我们调用check_for_new_submodule_commits()which 收集所有必须检查子模块更改的对象calculate_changed_submodule_paths()。
在第一次调用时，它还会收集所有现有的 refs 以将它们从扫描中排除。

calculate_changed_submodule_paths()创建一个包含所有收集到的新对象的参数数组，然后是 --not 和所有旧对象。这argv被传递给setup_revisions,which 解析每个参数，将其转换回 oid 并解析对象。
解析本身也做了多余的工作，因为它被视为用户输入，而实际上它是一个完整的 oid。因此它不必要地尝试将其查找为 ref （检查它是否有^等~），检查它是否是文件名等。

对于具有许多 ref 的存储库，所有这些都是昂贵的。但是如果超项目中的 fetch 没有更新 ref（即子模块中需要存在的对象没有改变），则不需要将其包含在列表中。

在提交 be76c212之前（“ fetch：确保获取子模块对象”，2018-12-06，Git v2.21.0-rc0 --批次 #4中列出的合并），仅检测到已更改的 refs 的子模块引用更改，但未检测到新的参考文献。该提交也涵盖了这种情况，但它所做的只是包含每个 ref。

此更改应将扫描的 refs 数量减少大约一半（除了 no-op fetch 的情况，它不会扫描任何 refs），因为所有现有 refs 仍将列在--not.

于 2020-09-24T21:26:08.297 回答
0

Git 非常快，但如果你的 repo 非常大，下载整个历史记录可能需要一些时间。

一种选择是使用or的--depth 1参数。这个参数告诉 git 只下载最近的提交，而不是完整的历史。您将无法在提交、查看差异等之间切换，但由于这是针对构建环境的，因此您不需要任何这些。git clonegit fetch

于 2019-09-15T16:20:22.060 回答