Итак, я знаю о хуках git и буду изучать их дальше, но хочу написать простой сценарий bash, запускаемый через cron, чтобы поддерживать репозиторий на удаленном сервере в актуальном состоянии. Я представляю, как это работает:
В настоящее время у меня это работает как задача cron, которая выглядит так:
*/1 * * * * cd /my/sites/staging && git pull -q origin master && grunt production
Я пытаюсь избежать запуска моей сборки grunt, если ничего не изменилось. Думаю, все сводится к тому, как я могу узнать, действительно ли git pull что-нибудь потянул, и использовать это как условие для запуска моей сборки grunt. Сервер Ubuntu, ключ установлен на github, и все такое хорошее. Спасибо за любую помощь!
Обе проблемы (автоматическая обработка ваших развертываний и избежание бесполезной работы, например, запуск grunt задача если ничего не изменилось) какие git крючки для.
Итак, мой совет - избавиться от cron задач и как можно скорее переключитесь на управление репозиториями через хуки.
Как это обычно делается, подробно описано. Вот, и в основном требует наличия bare репозиторий (a концентратор репо) для отправки / извлечения и извлеченная версия того же репо ( жить репо), расположенный по соответствующему пути, скажем /srv/www/html, например.
Я люблю использовать gitolite3 справиться с концентратор репо, но это не обязательно, хотя иметь детальный контроль доступа, привязанный к выбранному вами LDAP если нужно.
Также хорошей практикой является ограничение возможностей gitolite3 пользователь через sudo, и держите крючки с помощью sudo звонки. Это рабочий пример с использованием gitolite3 крючки (не стесняйтесь адаптировать их - или улучшать / исправлять - в соответствии с вашими потребностями):
концентратор репо post-update крючок:
#!/bin/sh
echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"
sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
exit 0
publisher-hub2live сценарий:
#!/bin/sh
echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"
cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master
# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info
exit 0
А жить репо post-commit также может быть полезен, если вы когда-нибудь будете вносить изменения в извлеченное рабочее дерево жить репо и хотите синхронизировать хаб.
Эта инфраструктура требует следующих записей (или эквивалентных) в вашем sudoers файл:
Cmnd_Alias GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3 ALL = (root)NOPASSWD: GITOLITE_CMDS
Также Match блокировать в вашем sshd_config было бы полезно, в зависимости от того, как вы управляете идентификацией на своих машинах:
Match Group gitolite3
Banner /etc/issue.empty
RequiredAuthentications2 publickey
Имея все это на месте, подталкивая к концентратор репо запускает post-update ловушка, гарантирующая выполнение ваших пользовательских действий только когда есть что-то новое.
Я думаю, вы можете решить эту проблему, просто сделав это:
*/1 * * * * cd /my/sites/staging && git pull -q origin master|grep -v "up-to-date" && grunt production
Хотя я сам не использовал его из-за моего понимания марионетки http://puppetlabs.com/ ты можешь сделать это.
Каждый раз, когда марионетка запускается, если что-то меняется, она автоматически отправляется на другие серверы в зависимости от того, что такое золотой образ. И если у вас есть большое количество серверов после создания золотого образа, вы можете создать марионетку базовой установки на другом, и новый сервер получит остальную часть конфигурации с главного сервера.