Опрос бесконечного цикла Hudson на наличие изменений в репозитории Git?

Question

Плагин git для Hudson работает хорошо.Однако сценарий сборки должен обновить номер версии в файлах в репозитории, зафиксировать и отправить обратно в репозиторий.

Когда Hudson выполняет опрос, чтобы проверить наличие изменений, он переходит в бесконечный цикл, поскольку видит, что фиксация как «изменение» строится снова, что фиксирует изменение, поэтому он строит снова, затем фиксирует еще одно изменение и т. д.Вы поняли идею.

Я остановил его, запустил «git log» в каждом репозитории и сравнил, что последние идентификаторы коммитов точно такие же, используя git ls-tree HEAD.

Кроме того, Hudson запускает эту команду для проверки изменений:

git fetch +refs/heads/:refs/remotes/origin/git ls-дерево HEAD

Поскольку Hudson сам отправил коммит из своего репозитория рабочей области и, очевидно, результаты ls-tree совпадают, как эта команда может определить, что произошли изменения?

Кажется, что он должен сохранять результаты ls-tree перед выполнением сборки и сравнивать их с тем, у которого не будет последней фиксации.Ах.Я могу попробовать отключить фиксацию, чтобы проверить эту теорию.

В любом случае, вместо того, чтобы исправлять какие-либо проблемы в плагине git для Hudson, что я могу сделать, чтобы в конце сборки убедиться, что репозитории идентичны и что Hudson увидит это так?

Как это исправить?Есть идеи?

Уэйн

Answer 1

И ответ!...

Плагин Git Hudson уже был кем-то разветвлен, чтобы добавить эту функцию, и он работает хорошо.Тем не менее, мне пришлось удалить исходный код и исправить пару мелких проблем.

Теперь это работает прекрасно.Сборка фиксируется, и плагин Git возвращает в репозиторий без зацикливания, думая, что он снова изменился.

Замечательный!

Если кому-то еще это нужно, найдите ответвление Tickzoom плагина Hudson-GIT-Plugin на Github.com, но проверьте, не интегрирован ли он уже обратно в основной проект.Коммиттер сказал, что он заинтересован и планирует объединить форки.

Уэйн

Answer 2

Ваша система сборки не должна взаимодействовать с вашей системой контроля версий при записи.Это определенно не должно толкать эти изменения автоматически.

Ваша система сборки может просить мерзавец (через git describe, например) какая текущая версия.Все остальное избыточно и подвержено ошибкам.

Еще одна вещь, которую вы можете рассмотреть, — это не опросить изменения.Это кажется глупым способом действовать.(Признаюсь, я активно пользуюсь ботами-сборщиками, привыкшими к тому, что все активируется по событиям.)

Репозиторий git, который опрашивается, знает, когда он меняется.Он должен просто указать системе CI немедленно начать сборку на основе этого.Вы получаете свои сборки раньше, и, поскольку все они запускаются, ваши компьютеры не сидят без дела и выполняют большую работу без уважительной причины.