如何将构建输出从一个git repo集成到另一个?

I am working on a 2 projects which are stored in 2 git repos Project1 and Project2

我正在做一个2个项目，它们存储在2 git repos Project1和Project2中

Project1 is a javascript project. It has its own repo (for example https://github.com/gandra/project1.git)
Project2 is a java maven project. It has its own repo (for example https://github.com/gandra/project2.git)

Project1是一个javascript项目。它有自己的repo(例如https://github.com/gandra/project1.git) Project2是一个java maven项目。它有自己的repo(例如https://github.com/gandra/project2.git)

Here is a current workflow which I want to improve:

下面是我想改进的一个工作流:

Commit changes in a Project1 and push it to origin
提交项目1中的更改并将其推到原点
Run grunt in a Project1. This generates Project1/build directory
在项目1中运行咕哝。这个生成Project1 /构建目录
Manually copy Project1/build contents into Project2/libs/project1-lib directory
手动将Project1/build内容复制到Project2/libs/ Project1 -lib目录
Commit changes(Project2/libs/project1-lib) in Project2
提交修改Project2(Project2 / libs / project1-lib)
Runk jenkins build and deploy
Runk jenkins构建和部署

I want to somehow to avoid step 3 (manual copy of Project1/build contents into Project2/libs/project1-lib directory) I thought about integrate Project1 into Project2 as a subtree but the problem with this approach is beacuse it gets all Project1 directory structure into Project2/libs/project1-lib and I want only to take subdirectory of a Project1 (Project1/build/*)

我想避免步骤3(手动复制Project1 /内容构建到Project2 / libs / project1-lib目录)我想到Project1融入Project2一个子树,但这种方法的问题是吧,都Project1目录结构到Project2 / libs / project1-lib我只想把Project1的子目录(Project1)/构建/ *

Some important note: Project1 changes occurs only in its own repo(https://github.com/gandra/project1.git) and this change should be propagated to Project2. So there is no update of Project1 from Project2/libs/project1-lib In other words:
- Commits in Project1 affect Project2
- commits in Project2 not affects Project1

一些重要的注意事项:Project1更改仅发生在它自己的repo(https://github.com/gandra/project1.git)中，并且该更改应该传播到Project2。所以Project2/libs/ Project1 -lib中没有对Project1的更新，换句话说:-在Project1中提交会影响Project2 -在Project2中提交不会影响Project1

4 个解决方案

#1

Ok let's recap the most important facts here:

让我们来回顾一下最重要的事实:

Project2 is maven project(with war packaging probably, since you will deploy it ).
Project2是maven项目(可能带有war打包，因为您将部署它)。
Project2 depends on Project1 in a way that it expects his output build on a path Project2/libs/project1-lib
Project2依赖于Project1，它期望在路径Project2/libs/ Project1 -lib上构建输出

In my opinion builds(even partial buils) are not meant to be under any source code management, so I wouldn't reserve any path of Project2 like Project2/libs/project1-lib to be under the git. Maven war plugin has this nice feature maven-war-plugin-overlays. So if Project2 would see Project1 as maven dependency with war type of packaginig e.g.

在我看来，构建(甚至是部分构建)不应该在任何源代码管理之下，所以我不会将Project2/libs/project1-lib之类的Project2路径保留在git之下。Maven war插件有这个不错的特性:Maven -war-plugin-overlay。所以如果Project2将Project1视为maven依赖，带有packaginig的war类型。

  <dependencies>
    ...
    <dependency>
      <groupId>your.group.id</groupId>
      <artifactId>project1</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>war</type>
      <scope>runtime</scope>
    </dependency>
    ...
  </dependencies>

, you wouldn't have to do any coping into Project2/libs/project1-lib location, because that will maven do for you in phase of packaing. But to do this, you have to install war artifact of your Project1 into your nexus. There are couple of solutions here:

，您不必对Project2/libs/project1-lib位置进行任何处理，因为maven将在打包阶段为您做这些工作。但是要做到这一点，您必须将项目1的war工件安装到您的nexus中。这里有几个解决方案:

Solution 1)

解决方案1)

Make Project1 to be fully maven project, and make sure output of build finished on a path ./libs/project1-lib in his war. Since Project1 now would be build with maven, you would have to integrate previous building tool of Project1(grunt, gulp or whichever) to be called by maven in some phase before packaging phase.
使Project1成为完全的maven项目，并确保在路径上完成构建的输出。因为Project1现在将使用maven构建，所以您必须在打包阶段之前的某个阶段集成先前的Project1构建工具(grunt, gulp或其他)，由maven调用。

In Project2 add new dependency like this:

在Project2中添加新的依赖项:

<dependency>
  <groupId>your.group.id</groupId>
  <artifactId>project1</artifactId>
  <version>1.0-SNAPSHOT</version>
  <type>war</type>
  <scope>runtime</scope>
</dependency>

Solution 2).

2)解决方案。

With your current builder of Project1, make sure you package your project into war with following structure ./libs/project1-lib. Using same builder install this as war artifact on your nexus (NOTE: you would have to have pom.xml installed on your nexus so other project can reference Project1) If you are using grunt as a js builder luckily, there is this npm component grunt-nexus-deployer which will do exactly what I described here.
使用当前的Project1构建器，请确保使用以下结构将项目打包为war。使用相同的构建器在您的nexus上安装这个作为war工件(注意:您必须有pom。在您的nexus上安装的xml，以便其他项目可以引用Project1)如果您使用grunt作为js构建器，幸运的是，有一个npm组件grunt-nexus部署器，它将执行我在这里描述的操作。
same as for Solution 1)...
和解决方案1一样……

Explanation:

解释:

When you push your changes of Project1 your CI will trigger job which will install project1-1.0-SNAPSHOT.war on your nexus after this is done, CI job for Project2 will be triggered and it will have everything needed for project2 build.

当您推动您对Project1的更改时，您的CI将触发将安装Project1 -1.0- snapshot的作业。在此之后，Project2的CI工作将被触发，它将拥有Project2构建所需的一切。

NOTE: In both solutions, delete Project2/libs/project1-lib hierarchy, since it not used anymore...

注意:在两个解决方案中，删除Project2/libs/project1-lib层次结构，因为它不再使用了…

EDIT:

编辑:

For solution 2) maybe you should use grunt-maven-tasks instead of grunt-nexus-deployer because it has more options and it is more suitable.

对于解决方案2)也许你应该使用grunt-maven-tasks而不是grunt-nexus-deployer，因为它有更多的选项，也更适合。

#2

If you control the Git server you're using, then you can accomplish what you're asking for by using a post-receive server-side hook.

如果您控制了正在使用的Git服务器，那么您可以通过使用后接收服务器端挂钩来完成您所要求的任务。

However, I can't help feeling that there should be a better approach than pushing changes from Project1 to Project2. It's obvious that Project1 is Project2's dependency. I'm more used to handling dependencies the way they do it with Maven and Gradle:

然而，我忍不住觉得应该有一种比将变更从Project1推到Project2更好的方法。显然，Project1是Project2的依赖项。我更习惯使用Maven和Gradle处理依赖项的方式:

Have the build tool (e.g. Gradle) for Project1 publish the build artifacts into a build artifact repository (e.g. Artifactory).
让Project1的构建工具(例如，Gradle)将构建工件发布到构建工件存储库中(例如，Artifactory)。
Have the build tool for Project2 pull the latest artifacts from the build artifact repository as needed.
让Project2的构建工具根据需要从构建工件存储库中提取最新的工件。

The advantages that I see in this approach are:

我在这种方法中看到的优点是:

Project1 is independent from Project2. Since it's Project2 that needs Project1 (and not vice-versa), it shouldn't be Project1's responsibility to keep Project2 updated.
Project1独立于Project2。因为Project2需要Project1(反之亦然)，所以Project1不应该有责任更新Project2。
Project2 is in control of how it consumes Project1. You are free, for example, to freeze the dependency at a certain Project1 release (e.g. because Project1 is currently broken and you want to keep developing Project2 without waiting for the fix).
Project2可以控制它如何使用Project1。例如，您可以在某个Project1发行版中冻结依赖项(例如，因为Project1目前已经崩溃，您希望不等待修复而继续开发Project2)。
You're not polluting Project2's commits with changes that are unrelated to Project2's source. If every time Project1 is updated you get a new commit in Project2, soon enough it'll make your life difficult when it comes to merging, rebasing, bisecting or any number of other things you normally have to do.
您不会用与Project2源无关的更改来污染Project2的提交。如果每次Project1被更新，你就会在Project2中得到一个新的提交，很快就会使你的生活变得困难，当你需要合并、重设基础、分割或者其他一些你通常需要做的事情时。

The disadvantages lie mainly in the infrastructure requirements (suddenly you need yet another server) and in choosing and configuring your build tools. When it comes to Java, I would recommend Gradle hands down for the build tool and Artifactory for the build artifact repository. But you said your Project1 is Javascript and I haven't worked in that ecosystem, so I don't have any good recommendations there.

缺点主要在于基础设施需求(突然需要另一个服务器)和选择和配置构建工具。当涉及到Java时，我建议为构建工具提供Gradle，为构建工件存储库提供Artifactory。但是你说你的Project1是Javascript，我没有在那个生态系统中工作过，所以我没有任何好的推荐。

Edit: I just now realized that I mixed up Project1 and Project2. The question says Project2 consumes Project1 and my initial answer was written as if Project1 consumed Project2. I fixed that now, to avoid confusion.

编辑:我刚刚意识到我把Project1和Project2搞混了。问题是，Project2消耗了Project1，我最初的答案被写成好像Project1消耗了Project2。为了避免混淆，我现在把它修好了。

#3

What Vojislav said is correct. The building of the two projects (in the way you described it) should be decoupled. If the final product needs both components, then it is the build tool's (jenkins) job to compose the application. The two projects should be pretty agnostic of each other.

Vojislav的说法是正确的。这两个项目(按照您描述的方式)的构建应该是分离的。如果最终产品需要这两个组件，那么构建工具(jenkins)的工作就是构建应用程序。这两个项目应该是互不相干的。

I haven't used Jenkins in a little while but in Bamboo I would have one task called BuildProduct which would have two tasks (Build Project 1) and (Build Project 2) where the building of Project 2 would use the result of the first build (the built JS).

我在一段时间内没有使用Jenkins，但是在竹子中，我将有一个任务叫做BuildProduct，它将有两个任务(构建项目1)和(构建项目2)，其中项目2的构建将使用第一个构建的结果(构建的JS)。

#4

Have you considered Gradle instead of Maven?

你考虑过等级生而不是专家吗?

https://blog.oio.de/2014/10/24/handling-javascript-dependencies-with-gradle/

#1