即使没有新的提交,Jenkins Poll SVN 也会不断构建

发布于 2024-12-01 17:57:29 字数 954 浏览 0 评论 0原文

我正在尝试设置 Jenkins 从我的 SVN 存储库进行轮询,并在检测到提交已进入时启动新的构建。我已经使轮询部分正常工作,但该构建相当过分热心,现在正在重建每次轮询时 - 无论是否有任何变化。 SCM-polling.log 文件显示:

Started on Aug 31, 2011 9:49:51 AM
Workspace doesn't contain svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk. Need a new build.
Done. Took 10 ms
Changes found

Jenkins 的控制台输出如下所示:

Started by an SCM change
Checking out a fresh workspace because the workspace is not svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
Cleaning workspace /var/lib/jenkins/jobs/CSATester/workspace
Checking out svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
....
no revision recorded for svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk in the previous build
No changesets found for this build

The repo url is set to svn://10.64.147.118:/svn/repos/conttest/trunk 并且我告诉 Jenkins 删除未版本控制的文件然后在构建之前更新。工作空间肯定包含存储库中的文件,并且每次构建都会成功。

关于可能导致这种情况的原因有什么想法吗?

I'm trying to setup Jenkins to poll from my SVN repo, and start a new build whenever it detects a commit has gone in. I've gotten the polling part working, but the building is rather overzealous, and right now it is rebuilding every time it polls - whether or not there have been any changes. The SCM-polling.log file reads:

Started on Aug 31, 2011 9:49:51 AM
Workspace doesn't contain svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk. Need a new build.
Done. Took 10 ms
Changes found

The Console Output from Jenkins looks like this:

Started by an SCM change
Checking out a fresh workspace because the workspace is not svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
Cleaning workspace /var/lib/jenkins/jobs/CSATester/workspace
Checking out svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
....
no revision recorded for svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk in the previous build
No changesets found for this build

The repo url is set to svn://10.64.147.118:/svn/repos/conttest/trunk and I've told Jenkins to delete unversioned files and then update prior to build. The work space definitely contains the files in the repo, and the build succeeds every time.

Any ideas on what may be causing this?

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

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

发布评论

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

评论(4

你爱我像她 2024-12-08 17:57:30

所以,我发现 Jenkins 或 SVN 插件似乎都不支持 svn:// 协议。将我的 SVN 服务器更改为使用 http:// 并在 Jenkins 中设置新路径后,除非实际上有新的提交,否则不再进行构建。

TL,DR:不要使用 svn://,而是使用 http://。

So, I've found out that it seems the svn:// protocol isn't supported in either Jenkins or the SVN plugin. After changing my SVN server to use http:// and setting that new path in Jenkins, builds are no longer happening unless there is actually a new commit.

TL,DR: Don't use svn://, use http:// instead.

野の 2024-12-08 17:57:30

我不确定是什么原因造成的,但过去我在 SCM 轮询方面遇到过很多问题。我发现编写一个 SVN 提交后触发器来点击构建的 url 来触发它效果更好。这消除了轮询的开销,并且如果没有更改则永远不会触发构建。如果您想变得更奇特,您甚至可以使触发器“更智能”并避免对 readme.txt 等文件的更改进行编译。

I'm not sure what is causing this, but I've had a lot of issues with SCM polling in the past. I've found that it works better to write an SVN post-commit trigger that hits the url of the build to trigger it. This eliminates the overhead of polling and will never trigger a build if there are no changes. If you wanted to get fancy, you could even make the trigger 'smarter' and avoid compilation on changes of files like readme.txt and the like.

涙—继续流 2024-12-08 17:57:30

我们在 CVS 上也遇到了类似的问题,其中 CVS 轮询花费的时间比我告诉它轮询更改的时间要长。也就是说,CVS 需要三分钟来轮询更改,但我告诉它每分钟轮询一次。不过,这不应该是 Subversion 的问题。

您可以使用 Feasoron 所说的提交后挂钩,但这种方法有两个问题:

  • 如果 Jenkins/Hudson 宕机当触发时,Jenkins/Hudson 将不会进行构建。
  • 如果 Jenkins/Hudson 服务器之间存在任何时间差异(即使只有几秒钟),您最终可能会由 Jenkins/Hudson 构建版本的存储库。

大多数人在 Jenkins/Hudson 中进行 Subversion 轮询,但没有这些问题,因此它可能与您的设置中的某些内容有关。

查看每个构建的轮询日志,了解为什么 Jenkins/Hudson 认为它看到了更新(在每个构建中作为网页左侧的链接提供)。另请查看构建控制台的前几行,看看是否提供了任何线索。

如果您仍然无法弄清楚,请使用一些轮询日志更新您的问题,这可能有助于我们了解您遇到这些问题的原因。

We had a similar issue with CVS where the CVS polling took longer than the time I told it to poll for changes. That is, it would take CVS three minutes to poll for changes, but I was telling it to poll every minute. This shouldn't be an issue with Subversion though.

You can use a post commit hook as Feasoron said, but there are two issues with that approach:

  • If Jenkins/Hudson is down when the trigger is hit, Jenkins/Hudson won't do a build.
  • If there is any time difference between the Jenkins/Hudson server (even just a few seconds), you could end up with Jenkins/Hudson building the older version of the repository.

Most people have Subversion polling in Jenkins/Hudson and don't have these issues, so it's probably related to something in your setup.

Take a look at the polling logs for each build and see why Jenkins/Hudson believes it sees an update (available in each build as a link on the left hand side of the webpage). Also look at the first few lines of your build console and see if that's offering any clues.

If you are still can't figure it out, update your question with a few of the polling logs and that might help us understand why you're having these issues.

我是有多爱你 2024-12-08 17:57:30

可能是SVN插件的问题。请参阅此处问题 10222

It could be an issue with the SVN plugin. See here Issue 10222.

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