Назад | Перейти на главную страницу

Проверка заданий Cron на наличие изменений в репозитории Git

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

Как можно настроить задание cron для проверки изменений в репозитории Git?

Greping выход git status команда может просто сделать это. Работа с grep и cron - не моя сильная сторона. Вот несколько примеров результатов git status:

Постоянная папка, содержащая репозиторий git (например, /path/gitrepo/) с измененными файлами:

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   apache2/sites-enabled/000-default
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   apache2/conf.d/test
no changes added to commit (use "git add" and/or "git commit -a")

Стоя в папке, когда есть без изменений:

$ git status
# On branch master
nothing to commit (working directory clean)

Обновить:

Синхронизация с источником не имеет значения. Никаких локальных изменений быть не должно. Локальные файлы, которые должны быть на месте, помещаются в файл .gitignore. В дополнение к конфигурациям сервера существуют также репозитории git для контента (статические веб-сайты, веб-приложения, wordpress и т. Д.). Ни в одном из репозиториев не должно быть локальных изменений.

Мы могли бы использовать Puppet в долгосрочной перспективе, поскольку он использовался для разработки одного из веб-приложений.

Вы должны использовать git ls-files

В -m flag получит список всех модифицированный файлы с момента последней фиксации. Если нет файлов модифицированный, данные не выводятся. Это упрощает настройку cronjob с помощью этой команды, поскольку cronjob по умолчанию отправляет письмо только в том случае, если команда что-то выводит.

Удалено файлы пр. определение модифицированный, поэтому они также будут отображаться в модифицированный Посмотреть. Если вы сделаете git ls-files -m -d, удаленные файлы будут перечислены дважды.

Однако обратите внимание, что git ls-files -m будут показывать только файлы модифицированный, и поэтому будет игнорировать неотслеживаемый файлы. Чтобы также показать неотслеживаемый файлы, вам необходимо передать -o флаг для "других файлов", а также передача опции --exclude-standard исключить файлы, перечисленные в .gitignore и .git/info/exclude.

Указание git dir и рабочего дерева

При запуске команды из cronjob вам нужно указать путь к .git dir и рабочее дерево с помощью --git-dir и --work-tree соответственно. Видеть git страницы руководства для справки.

Настройка Cronjob

Полная команда, которую вам нужно будет запустить в задании cron:

$ git --git-dir "/PATH/TO/DIR/.git" --work-tree "/PATH/TO/DIR" ls-files -m -o --exclude-standard

Ваш crontab должен выглядеть примерно так:

$ crontab -l
# m h  dom mon dow   command
* * * * * git --git-dir "/PATH/TO/DIR/.git" --work-tree "/PATH/TO/DIR" ls-files -m -o --exclude-standard

Каждую минуту будет отправляться электронное письмо при наличии изменений. Если вам нужна другая установка, я рекомендую вам проверить примеры в cron страница в Википедии.

Зачем git-ls-files?

Причина, по которой я рекомендую git ls-files над git status в том, что git status это так называемая "фарфоровая" команда, а git ls-files это «сантехническая» команда. Короче говоря, фарфоровые команды предназначены для вывода пользователю, в то время как команды сантехники предназначены для сценариев. Узнайте больше о различиях между командами git porcelain и git plumbing.

В своем вопросе вы игнорируете множество сложностей, поэтому я проигнорирую его в своем ответе:

if [ `git status | grep -c "working directory clean"` -ne 1 ]; then
    . . . you have changes . . .
else
    . . . you don't have any changes . . . 
fi

Обратите внимание, однако, что это не говорит вам, синхронизированы ли вы, являются ли локальные изменения законными, или действительно многое из того, что вы хотели бы знать, если есть изменения.

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