Непрерывная интеграция с Git

Я хотел бы обеспечить интеграционные хуки поверх Git, чтобы толчки отклонялись, когда интеграция не удалась. Например, когда разработчик вносит свои изменения, я хотел бы убедиться, что проект все еще успешно компилируется.

В настоящее время я установил хук после обновления для проверки компиляции. Однако, когда я хочу отклонить толчок, я отменяю изменения и информирую разработчика об этом:

git revert --no-edit HEAD
echo "Rejected !"

Моя проблема в том, что, когда другой разработчик хочет выдвинуть свои изменения, он должен сначала вытянуть, таким образом, переопределяя свою работу, а затем должен выполнить болезненные команды reset / stash для правильного объединения.

Более того, возврат не будет работать в случае слияния веток (для которого нужна опция -m)

Мой текущий обходной путь заключается в том, что вместо возврата на сервер я объединяю изменения в другой ветке (которая является исходной по умолчанию для моих разработчиков):

git checkout integrated
git merge master

Каков наилучший подход для достижения этой цели?

 innaM22 июн. 2013 г., 12:37
Позвольте вашим разработчикам запускать набор тестов локально. Вы можете автоматизировать это с помощью хука до фиксации. Если в любом случае возникнет ошибка, просто сделайте обычный возвратный коммит или коммит, исправляющий ошибку, и согласитесь с этим. Создание толчков длится несколько минут, потому что CI должен бежать, прежде чем им позволят, звучит для меня как очень плохая идея.

Ответы на вопрос(1)

Решение Вопроса

нных ветвей функций, которые имеют хук после обновления, который проверяет компиляцию, а затем объединяет ее с master (если вы хотите пойти по этому параноику, вы можете переместить хук в другую ветвь, которую вы объединяете). освоить вручную). Таким образом, вы нене нужно беспокоиться о том, что это будет отклонено. По моему мнению, мастер должен использоваться только как ветвь релиза как точка отсчета, а не то, к чему все подталкивают.

 Learath222 июн. 2013 г., 13:52
Ну, я пошел только с крюками после обновления, так как он сказал, что использовал их в своем вопросе, но Дженкинс тоже можно использовать.
 Klas Mellbourn22 июн. 2013 г., 13:30
Может быть, OP стоит заняться использованием Jenkins. Похоже, его можно настроить для поддержки этого сценария с помощьюСлить перед сборкой, Увидетьwiki.jenkins-ci.org/display/JENKINS/...
 3XX022 июн. 2013 г., 14:00
Спасибо ! Я хотел избежать дополнительных зависимостей, но да, может быть, Дженкинс это правильно

Ваш ответ на вопрос