我正在尝试设置jenkins-workflow来进行集成测试。我们的集成测试工作如下:
有人在git的功能分支中对LibraryA
进行了更改。我们希望jenkins针对功能分支中的代码运行单元测试,然后我们希望将此功能分支中的代码安装到client1
和client2
(LibraryA
的用户}并运行他们的测试。
我能够设置工作流来执行所有操作,除了获得LibraryA
的功能分支的正确提交。相反,我的设置只是从LibraryA
的一些(看似随机的)分支中提取。
我们有很多功能分支,因此在工作流程设置中对特定分支进行硬编码是不合适的。似乎应该有一些方法来获取触发工作流作业的提交的哈希值(即使使用SCM轮询)。
我的设置如下:
currentBuild.setDisplayName("#" + env.BUILD_NUMBER)
node {
git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: 'git@github.com:mycompany/myrepo.git'
sh '''
echo `git rev-parse HEAD` > libraryA_version.txt
sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests
'''
archive 'libraryA_version.txt'
}
def integration_jobs = [:]
integration_jobs[0]={
node{
ws {
unarchive mapping: ['libraryA_version.txt':'.']
sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"'
}
}
}
integration_jobs[1] = {
node{
ws {
unarchive mapping: ['libraryA_version.txt' : '.']
sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" '
}
}
}
parallel integration_jobs
所以,我当前的问题是我如何设置git repo / polling来获得在第一次测试中运行的正确提交,这将在后续测试中用于libraryA_version.txt
?
或者,我应该以完全不同的方式进行这个过程吗?
答案 0 :(得分:4)
正如@maybeg所暗示的那样,您最有可能寻找的是一个多分支项目,可以通过安装 Pipeline:Multibranch 来实现。这使您可以在Jenkinsfile
中定义脚本,只需在构建中调用checkout scm
一次或多次,从而无需libraryA_version.txt
。
与此同时,我对您的项目设置感到疑惑。您的git
步骤使用默认值branch: 'master'
,这意味着它应该只在master
分支上开始轮询,并且只检查此分支。 Git插件相当复杂,所以也许这会以某种方式破坏。在正确的多分支支持之前,您始终可以使用checkout
步骤并将GitSCM
配置为使用通配符分支规范,在这种情况下,将选择先前未构建的任意分支头进行结帐,并且{ {1}}技巧(我猜你独立重新发现JENKINS-26100的解决方法)应该按原样运作。
答案 1 :(得分:0)
您正在寻找的功能是Build-Per-Branch,在我看来,它应该通过适合用途的插件进行相应的实现。
分支在git中完成。
Jenkins必须复制构建或构建管道作业以适应分支,并能够构建和测试分支。
重新融入后,git必须告知Jenkins,Jenkins必须关闭这些工作。
我找到了这个插件:
https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin
这个插件/教程:
http://entagen.github.io/jenkins-build-per-branch/
实施很大程度上取决于您的方案,所以我不能更具体。我只是说挑战是:
构建可以并发且独立运行的Jenkins作业。
使用Jenkins作业的模板。
处理Jenkins和git之间的事件。
在你的情况下:
从前到后构建整个流程作为交付管道。
如果有人分支步骤并实现功能,则复制整个管道并运行整个管道。
让这个工作然后改进。