仅构建 Git 存储库的子目录时，Jenkins 会显示整个存储库的更改 - 为什么？

When building only a subdirectory of a Git repo, Jenkins shows the changes of the whole repo - why?

提问by eerriicc

We just migrated to Git, so if I ask stupid questions, please forgive me :-)

我们刚刚迁移到 Git，所以如果我问愚蠢的问题，请原谅我 :-)

Our Git repo contains several Maven projects, like this

我们的 Git repo 包含几个 Maven 项目，像这样

ssh://[email protected]:7999/foo/foo.git
   bar1
   bar2

I have separate Jenkins jobs to build bar1 and bar2. To prevent that a push to bar1 also triggers bar2, I configured the Git plugin in bar2 under Advanced... Included Regionsto include only bar2/.*- and vice versa in the bar1 job: bar1/.*

我有单独的 Jenkins 工作来构建 bar1 和 bar2。为了防止推送到 bar1 也触发 bar2，我将 bar2 中的 Git 插件配置为Advanced... Included Regions仅包含bar2/.*- 在 bar1 作业中反之亦然：bar1/.*

This works well, but there's one thing that nags me: The changes within both jobs show all the changes of the repo (bar1 and bar2) instead of just the changes of the specific project.

这很有效，但有一件事让我烦恼：两个作业中的更改显示了 repo（bar1 和 bar2）的所有更改，而不仅仅是特定项目的更改。

How can I configure that?

我该如何配置？

Screenshot:

截屏：

采纳答案by Lee

I'm assuming you mean the commit log when you refer to changes, in which case you cannot do what you require without a custom git client or at least a custom git commit viewer script.

我假设您在提及更改时指的是提交日志，在这种情况下，如果没有自定义 git 客户端或至少是自定义 git 提交查看器脚本，您将无法执行所需的操作。

A single repository should in theory only ever contain one project. Otherwise you are using git "wrong" (using the word "wrong" in a very loose sense as git is just a tool, using it wrong is impossible, there's just using it badly for your own requirements).

理论上，单个存储库应该只包含一个项目。否则，您将使用 git“错误”（在非常松散的意义上使用“错误”一词，因为 git 只是一个工具，错误使用它是不可能的，只是为了您自己的要求而使用它很糟糕）。

The only way to do what you want is to split the bar1 and bar2 folders into separate git repo's. If they are a bit like modules, which are both required on the same site, you could git init/clone into the bar1 and bar2 folders respectively for each project so you can control them separately.

做你想做的唯一方法是将 bar1 和 bar2 文件夹拆分为单独的 git repo。如果它们有点像模块，它们都在同一站点上需要，您可以将 git init/clone git init/clone 分别放入每个项目的 bar1 和 bar2 文件夹中，以便您可以分别控制它们。

Another alternative would be to separate them out into separate git repo's, then create a third "master" repo which just includes the two other repo's as sub-modules inside their respective folders. Then use a custom git hook as you probably already do, to make the master pull and build the correct folder/project/bar(x) . However this is a bit of a hacky way of doing things purely for the sake of not having to set up a few folders first.

另一种选择是将它们分成单独的 git 存储库，然后创建第三个“主”存储库，其中只包含另外两个存储库作为它们各自文件夹中的子模块。然后像你可能已经做的那样使用自定义的 git hook，让 master 拉取并构建正确的 folder/project/bar(x) 。然而，纯粹为了不必先设置几个文件夹，这是一种有点hacky的做事方式。

Basically put, you can't split out the commit log based on the folder, without writing your own custom commit viewer. You need to separate the project into multiple repo's. How you then bring them back to together and automate any build tasks, is up to you. There's no doubt more ways that the ones i mention above. Just a case of finding the best solution for your needs.

基本上，如果不编写自己的自定义提交查看器，就无法根据文件夹拆分提交日志。您需要将项目分成多个仓库。然后如何将它们重新组合起来并自动执行任何构建任务，这取决于您。毫无疑问，我上面提到的方法更多。只是为您的需求找到最佳解决方案的一个案例。

回答by Stew C

Verylate, but Jenkins always checks out the entire repo (even when doing sparse checkouts, Jenkins still clones the entire repo to local disk) and shows the revision of the repo as a whole on the build page.

非常晚，但是詹金斯始终检查出整个回购（甚至做稀疏检出时，詹金斯还在克隆整个回购到本地硬盘），并显示回购作为一个整体构建页面上的修订。

This was intended by the Jenkins developers. A core aspect of CI is being able to easily track changes across the history of a repo. Change tracking across a repo would become very difficult (and near impossible with large repos) if only the revision of a subdirectory was shown for each build.

这是 Jenkins 开发人员的意图。CI 的一个核心方面是能够轻松跟踪回购历史记录中的更改。如果每次构建只显示子目录的修订版，那么跨存储库的更改跟踪将变得非常困难（对于大型存储库几乎不可能）。