我正在尝试用Hudson替换我们当前的Buildbot设置。我安装了git插件。我们目前的设置如下:
ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git
现在,为了构建project_a
,我添加了一个包含多个git存储库的新作业(上面的那些)。我希望Hudson将存储库克隆到$WORKSPACE
下的不同目录中,因为test_framework
需要该层次结构。但是Hudson似乎将所有内容合并到$WORKSPACE
中。从控制台日志:
warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0
我可以在Hudson中配置它以更好地适应我们的项目设置吗?我是否需要为每个项目创建一个本地虚拟git存储库作为git子模块或什么?
答案 0 :(得分:6)
在Hudson中,您可以将多个工作链接在一起。您可以尝试为test_framework创建单独的Hudson作业,为project_a创建另一个Hudson作业。 Hudson在$ WORKSPACE中为每个作业创建一个单独的目录,所以现在你应该在$ WORKSPACE下有两个不同的目录。
设置链接
在project_a的作业配置中,向下滚动到Post-build操作并选中Build other projects ...输入test_framework作为要构建的项目。
在test_framework的作业配置中,确保Poll SCM 未选中,并将其他项目后的Build设置为project_a。
工作原理
您现在配置的是project_a将轮询SCM寻找更改,当发现更改时,它将从git中提取它们。运行构建步骤(如果有的话)并在完成时触发test_framework作业以从git(如果有)中提取更改并运行其构建步骤。
答案 1 :(得分:6)
“构建其他项目”解决方案的问题在于,如果对test_framework进行了更改,则不会触发project_a构建。相反,我建议放弃git插件并使用以下内容设置“Execute 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
接下来,使用以下内容创建挂钩文件“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
现在,只要将更改推送到任一存储库,挂钩就会使用Hudson的API来触发构建。
答案 2 :(得分:6)
我意识到这个问题很老但是我遇到了同样的问题并且使用这个页面充实了我自己的解决方案,似乎工作得非常好(即使它有点令人费解)。这个解决方案的大部分功劳应归功于克林顿(唯一的原因是我很难提交这个答案,因为他的回答似乎并不能解决需要在同一个基本目录中的多个存储库)。
假设您有两个存储库(A和B)。
步骤:
1)制作两个项目,从远程存储库A和B中提取代码。在任一存储库中放置任何必要的构建步骤。
2)制作第三个目录,不进行任何源代码管理。向此项目添加构建步骤以执行类似于以下的shell命令:
ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B
(你的路径可能不一样。自己查一下!)
现在,您可以添加依赖于A和B作为目录中姐妹的任何其他构建步骤。是的象征性链接!
3)将三个任务联系在一起。拉任务的顺序可能有关,也可能无关紧要(比我知道的要好),但没有源代码控制的任务应该是链中的最后一个链接。
答案 3 :(得分:1)
我遇到了同样的问题,目前通过为每个项目创建一个作业并使用Copy Artifact Plugin来构建依赖作业来解决它,即使对它的依赖关系进行了Git更新(这是为了避免构建)在我们依赖的项目更新过程中。)
因此project_a将从test_framework复制其所需的最新稳定工件,并且对测试框架的更新将触发project_a中的构建。 project_a仍然可以通过Git中的更改触发,它只是再次复制test_framework中的最新工件。
答案 4 :(得分:1)
您所描述的问题已在Jenkins bugtracker中作为错误提交:https://issues.jenkins-ci.org/browse/JENKINS-8082
我们使用扩展项目作业配置中的“自定义工作区”选项将我们作业的存储库签出到另一个作业的子目录中。
其他作业用所有子模块检出主目录:
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)