Подтвердить что ты не робот

Любой инструмент для создания git сборки каждой фиксации для ветки в отдельном репозитории?

Требуется инструмент A git, соответствующий спецификациям ниже. Уже существует ли это? Если нет, я создам script и сделаю его доступным в GitHub для других, чтобы использовать или вносить свой вклад. Существует ли совершенно другой и лучший способ решить необходимость сборки/тестирования каждой фиксации в ветке в репозитории git? Не только к последним, но и к каждой отправной точке.

Справочная информация. В нашей среде разработки используется отдельный сервер непрерывной интеграции, который является прекрасным. Тем не менее, по-прежнему необходимо делать полные сборки локально на каждом ПК разработчика, чтобы убедиться, что фиксация не будет "разбивать сборку" при нажатии на сервер CI. К сожалению, при автоматических модульных тестах эти сборки заставляют разработчика ждать 10 или 15 минут для сборки каждый раз.

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

Сейчас только одна главная проблема. Мы хотим удостовериться, что каждый отдельный сбор строит и передает тесты. Но мы часто занимаемся и пренебрегаем созданием нескольких новых коммитов. Тогда, если сборка завершится неудачно, вам нужно сделать bisect или вручную построить каждую промежуточную фиксацию, чтобы выяснить, какой из них сломался.

Требования к этому инструменту:

  • Инструмент будет искать другое репо, происхождение по умолчанию, выборку и сравнение всех коммитов, находящихся в ветвях, до 2 списков коммитов. В одном списке должны храниться успешно созданные коммиты, а остальные списки совершают неудачные.

  • Он идентифицирует любые коммиты, еще не внесенные в один список, и начинает строить их в цикле в том порядке, в котором они были совершены. Он останавливается на первом, который терпит неудачу.

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

  • Инструмент игнорирует любые "устаревшие" коммиты, которые предшествуют самому старому фиксации в списке успехов. Эта логика делает отправную точку возможной в следующей точке.

  • Начальная точка. Инструмент, создающий конкретное коммит, чтобы в случае успеха он был добавлен в список успехов. Если это самая ранняя фиксация в списке успехов, она становится "отправной точкой", так что ни одна из коммитов до этого не проверяется на сборку.

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

  • Если это не удастся при одном фиксации в ветке, оно остановится, не создавая остальных, которые последовали за ним. Вместо этого, если вы просто перейдете к другой ветке, если она есть.

  • Инструмент должен выполнить эти шаги один раз по умолчанию, но разрешить параметру цикл с возможностью установки количества секунд между циклами. Другие инструменты, такие как Hudson или CruiseControl, могут делать более интересные варианты планирования.

Инструмент должен иметь хорошие значения по умолчанию, но разрешить дополнительный контроль.

  • Какой репо? по умолчанию.

  • Какие ветки? все они по умолчанию.

  • Какой инструмент? по умолчанию исполняемый файл должен быть предоставлен пользователем с именем "buildtest", "buildtest.sh" "buildtest.cmd" или buildtest.exe "в корневой папке репозитория.

  • Задержка цикла запускается один раз по умолчанию с опцией цикла после нескольких секунд между итерациями.

4b9b3361

Ответ 1

Я написал инструмент, который я назвал git test-sequence некоторое время назад, чтобы сделать именно это.

Я просто рассматривал возможность вести блог об этом, потому что друг говорил мне, что это спасло ему массу работы на этой неделе.