Дженкинс: постоянная сборка SCM, несмотря на отсутствие изменений

У нас есть проблема, несмотря на отсутствие изменений кода. SCM запускает сборку. SCM опроса для изменений каждые 15 минут и должны только запускать сборку, если изменения найдены.

Вот несколько примеров последовательного журнала опроса SCM.

Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found

Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found

Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found

Как вы можете видеть, что ревизия такая же и совпадает с версией

Git Build Data

Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop

Эти задания вели себя так, как ожидалось, до нескольких дней назад. Мы ничего не знаем о том, что изменилось в нашей среде, чтобы вызвать это.

Я обновил до последней версии Jenkins (1.539) и установил плагины вчера вечером, пытаясь решить эту проблему, но поведение продолжается.

Ответ 1

Я просто столкнулся с Дженкинсом, постоянно строящим из-за изменения SCM, даже когда не было никаких изменений, и опрос даже не включался. Это может отличаться от вашего сценария, но я решил, что он все равно поможет поделиться моим решением.

Out project сконфигурирован для создания с использованием спецификатора ветки */integration точно так же, как и все наши другие сборки интеграции. Однако, посмотрев на все ветки нашего происхождения git repo, я увидел, что есть две ветки, которые соответствуют спецификатору */integration. Похоже, что разработчик ошибочно нажал на новую ветку с очень похожим именем:

$git branch --remote | grep integration
  origin/integration
  origin/origin/integration

Решение, которое исправило эту проблему для меня, заключалось в том, чтобы полностью указать ветвь, используя refs/heads/integration. Я предполагаю, что это также сработает, чтобы просто удалить дублирующуюся ветвь, но, указав ветвь точно, я могу избежать столкновения с той же проблемой в будущем.

Я не уверен, что это одна и та же причина для вашей проблемы, но это то, что сработало для меня, и, надеюсь, будет работать для кого-то еще в этой ситуации.

Ответ 2

Кажется, он воспроизводится с последним Jenkins GIT плагин версии 2.0.

Переход на версию 1.x может решить проблему. Хотя вы также должны вернуть конфигурацию Jenkins из старой резервной копии, поскольку GIT плагин версии 1.x, похоже, не работает с новой конфигурацией 2.0.

Этот поток предлагает включить "Быстрый удаленный опрос" в качестве обходного пути. В версии 2.0 он называется "Силовой опрос с использованием рабочего пространства". Я думаю.

Ссылка на проблему Дженкинса: https://issues.jenkins-ci.org/browse/JENKINS-20767

Ответ 3

Я столкнулся с той же проблемой.

Что исправлено для меня, заметив, что журнал опроса Git выглядел следующим образом:

Started on [date]
Using strategy: Default
[poll] Last Built Revision: Revision [commit#] (origin/develop)
[...]
Found 12 remote heads on ssh://[...]/repo.git
[poll] Latest remote head revision on refs/heads/feature/foo is: [commit#] - already built by 1414
[poll] Latest remote head revision on refs/heads/feature/bar is: [commit#] - already built by 2365
[poll] Latest remote head revision on refs/heads/feature/baz is: [commit#] - already built by 1489
[poll] Latest remote head revision on refs/heads/feature/qux is: [commit#] - already built by 1413
[poll] Latest remote head revision on refs/heads/develop is: [commit#] - already built by 2368
[poll] Latest remote head revision on refs/heads/master is: [commit#]
Done. Took 0.16 sec
Changes found

Обратите внимание, что строка для master не говорит "уже построенная". Я построил ветвь master и устранил проблему.

Ответ 4

Будьте осторожны с перенаправлением svn, в моем случае у меня был тот же случай, когда Дженкинс не мог определить, не изменилось ли svn и все время запускалось.

Проблема заключалась в том, что в моей конфигурации jenkins svn был этот url:

https://xxxx.yyy.es:443/svn/myproject/trunk и его перенаправление на

http://xxxx.yyy.es:8008/svn/myproject/trunk (я не знаю почему)

Дженкинс должен был быть настроен с последним URL-адресом, чтобы правильно определить изменения svn.

Это моя проблема.

http://antuansoft.blogspot.com.es/2014/10/jenkins-pool-smc-always-detect-changes.html

Ответ 5

Сегодня я столкнулся с этой проблемой. Это начало происходить, когда я добавил задачу "Удалить рабочее пространство при сборке". Я удалил эту задачу и, похоже, решил проблему.