LINUX.ORG.RU
решено ФорумAdmin

Уведомление на почту обо всех изменениях в репозитории (git commit, git pull)

 


0

1

Суть проблемы:

  • Имеется один сервис, у него имеются конфигурационные файлы;
  • Имеется центральный git-репозиторий, в котором хранятся эти файлы;
  • Имеется сервер, на котором размещен этот сервис. Репозиторий с конфигом склонирован на него.

Работа с этими конфигами происходят по двум сценариям:

Вариант 1:

  • Клонируем центральный репозиторий себе на тачку;
  • Редактируем конфиги, коммитим в локальную копию;
  • git push в центральный репо;
  • Опционально, сдергиваем на тестовый сервак, тестируем;
  • Топаем на боевой сервер, делаем git pull с центрального репо.

Вариант 2 (неправильный, но более простой, пригодный для мелких правок):

  • Редактируем конфиги прямо на боевом сервере, коммитим в локальную копию;
  • git push в центральный репо.

Есть необходимость в подписке на изменения в репозитории, находящемся непосредственно на боевом сервере. Как сделать подписку на изменения по второму варианту (обычный коммит) я разобрался (hooks/post-receive-email), а вот как сделать подписку на изменения, приходящие с git pull?

И сразу туда же: можно ли как-то отправлять не только уведомление, но и дифф?

★★★★

Последнее исправление: strangeman (всего исправлений: 2)

типа чтобы контролировать что там делают какие то засранцы? может просто проще засранцев оттуда выпилить?)

quest ★★★★
()

а вот как сделать подписку на изменения, приходящие с git pull?

Если я правильно понял, и все коммиты отправляются в главный репозиторий, то тамошний post-receive должен перехватывать всё, что потом может быть стянуто через git pull. Если вы боитесь, что кто-то поправил что-то на боевом сервере, то надо бить по рукам за такое. Если кто-то закоммитил с боевого сервера на главный, то в принципе какая разница, откуда пришёл коммит, главное чтоб в нужную ветку и с настроенным профайлом (просто чтоб было ясно, что коммит совершил не root@grendizer.com, а Петя Иванов ivanov@petya.ru)

можно ли как-то отправлять не только уведомление, но и дифф?

git diff?

Deleted
()
Ответ на: комментарий от quest

типа чтобы контролировать что там делают какие то засранцы?

Ага.

может просто проще засранцев оттуда выпилить?)

«Хочешь чтоб было сделано хорошо - сделай сам»? :) Не, там на часть рутинных изменений «засранцам» составлена инструкция и они работают строго по ней. Автоматизировать, увы, пока не получается, а самому этой рутиной заниматься лень, поэтому просто контролирую.

strangeman ★★★★
() автор топика
Ответ на: комментарий от Deleted

Если я правильно понял, и все коммиты отправляются в главный репозиторий, то тамошний post-receive должен перехватывать всё, что потом может быть стянуто через git pull.

В принципе да, можно просто обрабатывать post-receive на центральном сервере и не париться, наверное я зря пытаюсь решить задачу с другого бока.

git diff?

А как его можно увязать с post-receive-email? Чтобы не лезть в git, а пробегать глазами изменения непосредственно в почтовом клиенте.

strangeman ★★★★
() автор топика
Последнее исправление: strangeman (всего исправлений: 1)
Ответ на: комментарий от strangeman

«Хочешь чтоб было сделано хорошо - сделай сам»? :)

обычно это так) они ведь могут делать изменения и не делая git commit и/или git push

quest ★★★★
()
Ответ на: комментарий от quest

они ведь могут делать изменения и не делая git commit и/или git push

Замедление работы.

Чтоб не теоретизировать, опишу процесс. Работа идет с конфигом puppet, точнее с той его частью, в которой перечислены все ноды.

Процесс - развертывание клиентской машины.

  • Специально обученный мальчик (low-level anykey) берет тачку, ставит на нее убунту с диска (а-ля «далее-далее-далее»).
  • Ставит клиент puppet'а, отправляет запрос на сервер, принимает ключ клиента, типовая схема заведения клиента в паппет, в общем. На это ему дана инструкция в картинках.
  • Лезет на сервак паппета, прописывает ноду в определенный список (в какой - ему говорится заранее).
  • Коммитит данные в репозиторий на сервере, пушит в центральный репозиторий, опять же по инструкции в картинках. В принципе, тут и надо вешать post-recieve hook на центральный репозиторий, да и все, мне будет счастье.
  • Запускает паппет на клиенте, тот всасывает все нужные настройки с сервера согласно тому списку, куда клиент прописан.
  • Тачка отдается пользователю.

Т.е., вмешательство в конфиг хоть и минимально, но я всегда настраиваюсь на худшее и просматриваю дифф коммита, когда мне отзванивают и говорят, что машина отдана пользователю.

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

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

strangeman ★★★★
() автор топика
Ответ на: комментарий от strangeman

А как его можно увязать с post-receive-email? Чтобы не лезть в git, а пробегать глазами изменения непосредственно в почтовом клиенте.

git config hooks.showrev

Сам спросил, сам ответил. Все есть в документации.

strangeman ★★★★
() автор топика
Ответ на: комментарий от strangeman

А как его можно увязать с post-receive-email?

Вызови его там, очевидно же. Всё в post-receive выполняется уже после наложения прилетевшего коммита.

Кстати, глянул, оно там и так есть
[code]
echo «Summary of changes:»
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
[/code]
Чем не устраивает?

Deleted
()
Ответ на: комментарий от Deleted

Да-да, там даже опция есть для этого, ниже написал. Задачу можно считать решенной.

strangeman ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.