Seb*_*ian 5 continuous-integration artifactory continuous-deployment jenkins bitbucket-server
我不确定我是否可以在第一个问题中提供足够的信息,但我会尝试:
在我的公司,我们使用Stash.我的项目是一个多存储库项目(Client,Server,Common).我们使用Gitflow作为分支模型.模块本身都是Java,通过Ant构建,ivy用于依赖管理.到目前为止,我们"仅"使用我们的Jenkins实例来运行我们的测试并执行静态代码分析,因为我们的构建过程需要在专用环境中执行构建.因此,我们有一个Jenkins实例设置来从开发构建.公共项目是服务器和客户端项目之间的共享依赖项.因此,我们的Jenkins项目设置为common→{server,client}之间的下游依赖关系.公共项目包含一个构建后任务,用于在公司内部工件(JFrogg)中发布构建公共项目.然后在执行客户端和服务器jenkins项目(常春藤)期间使用它.
好的,我希望这能给出一个很好的概述.现在我的实际问题:
我们正在玩jenkins的Stash Pull请求插件,以便在我们为它们生成拉取请求时为我们的功能分支运行构建.但是,由于我们设置了依赖项,我想实现以下目标:
1)如果我们在Common和(Client或Server)中有相同票证的功能分支(Jira票号在分支中使用) - 首先构建公共 - 在附加jira票号的artifactory上发布common - 使用正确构建下游pull请求依赖(使用刚出版的构建对特定分支的artifactory)
2)如果我们只在公共项目中有一个功能分支 - 构建公共 - 在附加了jira票号的工件上发布公共 - 构建具有上述依赖性的下游开发分支(使用刚刚发布的具有特定分支的工件构建)
3)如果我们只在下游项目中有一个功能分支: - 使用已发表的工件的公共项目在服务器/客户端上构建功能分支.
使用默认设置(已经可以使用),我们实际上现在为所有构建做最后一个选项,一旦我们在客户端或服务器项目使用的公共项目中引入新功能,就会导致问题,因为功能分支将始终失败,直到我们合并功能分支并执行一次构建.
所以我想到了这样的解决方案:
有没有人知道这类问题的解决方案,或者可以指出我如何解决这个问题的方向？
非常感谢你的帮助,感谢抱歉.
最好,
塞巴斯蒂安
| 归档时间： |
|
| 查看次数： |
515 次 |
| 最近记录： |