在 Jenkins 中配置多个 Mercurial 存储库

发布于 2024-12-11 01:50:08 字数 1191 浏览 4 评论 0原文

我们使用大约 30 个存储库来处理我们公司的所有软件。我们的代码混合了 C#、C++ 和 python。我们最初打算使用 TeamCity 作为 CI 服务器,我发现按照我们的存储库系统的布局方式,设置起来非常容易。然而,我的经理决定我们应该使用 Jenkins。

当我开始设置 Jenkins 时,我发现它自然不支持每个作业的多个存储库。有一个插件可以实现此目的,但是在 wiki 页面 上该插件的维护者承认,它更多的是一个概念验证,而不是一个可靠的功能,所以我对使用它犹豫不决,尽管最终我可能被迫这样做。

作业是否应该独立于每个存储库进行设置,以便可以运行单元测试和构建?我不认为这是一个可行的选择,因为我们的存储库相互依赖,除非我缺少配置或不同的插件。或者构建可以相互依赖来使这样的事情成为可能吗?

我们的最终目标是让 Jenkins 也处理我们对开发暂存区域的部署。事实证明,这在 TeamCity 中很容易做到,而且我认为在 Jenkins 中也应该同样容易做到。一个作业可以访问其他作业的存储库吗?我不确定这是否清楚,但在 team city 中,有一些项目变量可以允许您选择已定义的任何存储库(即 %FIRST_REPO%%SECOND_REPO%< /code>)

总而言之,是否有一种可靠、干净的方法来处理 Jenkins 中的多个 Mercurial 存储库?其他作业可以依赖另一个作业并访问另一个作业的存储库吗?

我希望比我有更多 CI 经验的人可以提供帮助。也许不同的 CI 服务器更适合我们的设置,有人有使用 BuildBot 的经验吗?


我认为列出存储库的布局方式可能会有所帮助:

  • app1.application
  • app1.common
  • app1.deploy
  • app2.application
  • app2.common
  • app2.deploy
  • platform.common
  • platform.deploy

其中 app1 和 < code>app2 将依赖于 platform.common 中的一些资源。

We use about 30 repos to handle all of our software at our company. Our code is mixed between C#, C++ and python. We were originally going to use TeamCity for our CI server, and I found that extremely easy to setup with the way our repo system is laid out. However, my manager has decided we should use Jenkins instead.

As I started to setup Jenkins, I discovered that it does not naturally have support for multiple repositories per a single job. There is a plugin for this, but on the wiki page the maintainer of the plugin has admitted that it is more a proof-of-concept than a solid feature, so I'm hesitant to use it, though in the end, I may be forced to.

Should jobs be setup independent of each repo, where unit tests and builds can be run? I can't see that as being a viable option, since our repositories depend on each other, unless I'm missing a configuration or a different plugin. Or can builds depend on each other to make something like this possible?

Our ultimate goal is to have Jenkins also handle our deployments to our dev staging area. This proved to be easy to do in TeamCity, and I'm thinking it should be just as easy to do in Jenkins as well. Can a job access repositories from other jobs? I'm not sure if that's clear, but in team city, there were project variables that could allow you to choose any repo you've defined (i.e. %FIRST_REPO%, %SECOND_REPO%)

To summarize, is there a solid, clean way to handle multiple mercurial repositories in Jenkins? Can other jobs depend on another and access another's repository?

I'm hoping someone with more CI experience than I have can help. Perhaps a different CI server would work better for our setup, does anyone have experience with BuildBot?


I thought it might be beneficial to list how the repositories are laid out:

  • app1.application
  • app1.common
  • app1.deploy
  • app2.application
  • app2.common
  • app2.deploy
  • platform.common
  • platform.deploy

Where app1 and app2 will depend on some resources from platform.common.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

冷月断魂刀 2024-12-18 01:50:08

好吧,答案一直没有弄清楚。我们的解决方案是切换到 TeamCity,这使我们能够相当轻松地做到这一点。如果您指定,团队城市中的构建代理可以将存储库拉入不同的目录。从那里,存储库可以使用相对路径访问彼此的依赖关系。

我希望这对某人有帮助。在 Jenkins 中可能仍然有一种方法可以做到这一点,但我们无法找到一种直接的方法。

Well, the answer was never figured out. Our solution was switching to TeamCity, which allowed us to do it fairly easily. Build agents in team city can pull repositories into different directories, if you specify them to do so. From there, the repo's could access dependencies from each other using relative pathing.

I hope this helps someone. There may still be a way to do it in Jenkins, but we were not able to find a straight-forward way.

长不大的小祸害 2024-12-18 01:50:08

截至当前版本的 Jenkins & Mercurial 插件,它不支持从多个存储库中拉取。

但是,您可以通过链接作业(每个拉取一个作业)并让它们共享一个工作区来实现此目的。

As of the current version of Jenkins & the Mercurial plugin, it does not support pulling from multiple repos.

However, you can do this by having linked jobs, one job for each pull, and having them share a workspace.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文