使用 Hudson 并通过多个 git 存储库构建步骤

Using Hudson and build steps with multiple git repositories

提问by pojo

I'm trying out Hudson to replace our current Buildbot setup. I installed the git plugin. Our current setup is like:

我正在尝试使用 Hudson 来替换我们当前的 Buildbot 设置。我安装了 git 插件。我们目前的设置是这样的：

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

Now, to build project_aI added a new job with multiple git repositories (the ones above). I wanted Hudson to clone the repositories into different directories under $WORKSPACE, becase test_frameworkneeds that hierarchy. But Hudson seems to merge everything into $WORKSPACEinstead. From the console log:

现在，为了构建，project_a我添加了一个带有多个 git 存储库（上面的那些）的新作业。我希望 Hudson 将存储库克隆到 下的不同目录中$WORKSPACE，因为test_framework需要该层次结构。但是哈德森似乎将所有东西都合并了$WORKSPACE。从控制台日志：

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

Can I configure this in Hudson to better fit our project setup? Do I need to create a local dummy git repository with every project as git submodules or something?

我可以在 Hudson 中配置它以更好地适应我们的项目设置吗？我是否需要为每个项目创建一个本地虚拟 git 存储库作为 git 子模块或其他东西？

采纳答案by Clinton

Within Hudson you can chain multiple jobs together. You could try creating separate Hudson jobs for test_framework and another for project_a. Hudson creates a separate directory in $WORKSPACE for each job, so now you should have two different directories under $WORKSPACE.

在 Hudson，您可以将多个工作链接在一起。您可以尝试为 test_framework 创建单独的 Hudson 作业，为 project_a 创建另一个。Hudson 在 $WORKSPACE 中为每个作业创建了一个单独的目录，所以现在您应该在 $WORKSPACE 下有两个不同的目录。

---

---

Setup Chaining

设置链接

In the job configuration of project_a scroll down to Post-build actions and check Build other projects... Enter in test_framework as the project to build.

在 project_a 的作业配置中向下滚动到 Post-build actions 并选中 Build other projects... 输入 test_framework 作为要构建的项目。

In the job configuration of test_framework ensure that Poll SCM is uncheckedand that Build after other projects is set to project_a.

在 test_framework 的作业配置中，确保未选中Poll SCM并且将 Build after other projects 设置为 project_a。

---

---

How it works

这个怎么运作

What you have now configured is project_a will poll the SCM looking for changes, when changes are found it will pull them from git. Run build steps (if any) and on completion trigger the test_framework job to pull changes from git (if any) and run its build steps.

您现在配置的是 project_a 将轮询 SCM 以查找更改，当发现更改时，它将从 git 中提取它们。运行构建步骤（如果有）并在完成时触发 test_framework 作业以从 git（如果有）中提取更改并运行其构建步骤。

回答by scribnerc

The problem with the "Build other projects" solution is that if there are changes to test_framework it will not trigger project_a to build. Instead, I recommend abandoning the git plugin and setting up an "Execute shell" build step with the following:

“构建其他项目”解决方案的问题在于，如果 test_framework 发生更改，则不会触发 project_a 进行构建。相反，我建议放弃 git 插件并使用以下内容设置“执行 shell”构建步骤：

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

Next, create hook files "server:/repo/test_framework.git/hooks/post-receive" and "server:/repo/project_a.git/hooks/post-receive" with the following content:

接下来，创建钩子文件“server:/repo/test_framework.git/hooks/post-receive”和“server:/repo/project_a.git/hooks/post-receive”，内容如下：

#!/bin/sh
curl http://hudson/job/job_name/build

Now, whenever changes are pushed to either repository, the hook will use Hudson's API to trigger a build.

现在，每当将更改推送到任一存储库时，挂钩将使用 Hudson 的 API 来触发构建。

回答by Peter Enns

I realize this question is very old but I ran into the same problem and used this page to flesh out my own solution that seems to be working really well (even though it is a tad convoluted). Most of the credit for this solution should go to Clinton (the only reason I'm bothering to submit this answer is because his answer doesn't seem to address multiple repositories that need to be in the same base directory).

我意识到这个问题很老了，但我遇到了同样的问题，并使用此页面充实了我自己的解决方案，该解决方案似乎非常有效（即使它有点令人费解）。这个解决方案的大部分功劳应该归功于克林顿（我费心提交这个答案的唯一原因是他的答案似乎没有解决需要在同一个基本目录中的多个存储库）。

Suppose you have two repositories (A and B).

假设您有两个存储库（A 和 B）。

Steps:

脚步：

1) Make two projects to pull code from remote repositories A and B. Put any necessary build steps in either repository.

1) 制作两个项目以从远程存储库 A 和 B 中提取代码。将任何必要的构建步骤放在任一存储库中。

2) Make a third directory without any source control management. Add a build step to this project to execute a shell command similar to this:

2）制作第三个目录，没有任何源代码控制管理。向这个项目添加一个构建步骤来执行一个类似于这样的 shell 命令：

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

(Your paths may not be the same. Look them up yourself!)

（你的路径可能不一样。你自己查一下！）

Now you can add any other build steps that depend on A and B being sisters in a directory. Yay symbolic links!

现在，您可以添加任何其他依赖于 A 和 B 是目录中姐妹的构建步骤。是的符号链接！

3) Chain the three tasks together. The order of the pull tasks may or may not matter (you know better than I do) but the task without source control should be the last link in the chain.

3) 将三个任务链接在一起。拉取任务的顺序可能重要也可能无关紧要（你比我更清楚）但没有源代码控制的任务应该是链中的最后一个环节。

回答by cweiske

The problem you are describing is already filed as bug in the Jenkins bugtracker: https://issues.jenkins-ci.org/browse/JENKINS-8082

您所描述的问题已经在 J​​enkins bugtracker 中作为错误提交：https: //issues.jenkins-ci.org/browse/JENKINS-8082

---

---

We use the "custom workspace" option in the extended project job configuration to checkout our job's repository into a subdirectory of another job.

我们使用扩展项目作业配置中的“自定义工作区”选项将我们的作业存储库检出到另一个作业的子目录中。

That other job checks out the main directory with all submodules:

另一个作业检查主目录和所有子模块：

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)

回答by Viesti

I ran into the same problem and currently solved it by creating a job for each project and using the Copy Artifact Pluginto allow building the dependent job even if a Git update is done on it's dependencies (this is to avoid building in the middle of an update to the project which we depend upon).

我遇到了同样的问题，目前通过为每个项目创建一个作业并使用Copy Artifact Plugin允许构建依赖作业来解决它，即使在它的依赖项上完成了 Git 更新（这是为了避免在中间构建）更新到我们依赖的项目）。

So project_a would copy the latest stable artifacts it needs from test_framework and an update to test framework would trigger a build in project_a. project_a can still be triggered by a change in Git, it just copies again the latest artifacts in test_framework.

因此，project_a 将从 test_framework 复制它需要的最新稳定工件，并且对测试框架的更新将触发 project_a 中的构建。project_a 仍然可以由 Git 中的更改触发，它只是再次复制 test_framework 中的最新工件。