Мониторинг изменений в каталоге с помощью Git и сборка Lume

9 min

gitlumegnugnu-linux
language: ja bn en es hi pt ru zh-cn zh-tw

Image
Здравствуйте, я Бездарь.
Некоторое время назад
Пересборка только при изменении в LumeCMS для статических сайтов SSG с использованием inotifywait
Я настроил автоматическую сборку таким образом, но она запускалась даже при создании swap-файлов vim, процессы иногда умирали, сборка запускалась без необходимости, и это было не очень стабильно, что меня беспокоило. Поэтому я подумал: «Если управлять этим с помощью git, то при изменениях можно запускать процесс сборки, а если что-то пойдет не так, можно будет откатиться, что неплохо», и поскольку у меня уже были идеи для написания некоторых скриптов, я решил попробовать.

Вот так

Вот код с самого начала, вкратце.
Он также опубликован на Github. 

#!/bin/bash

LUME_DIR="/your/lume/dir"
SRC_DIR="$LUME_DIR/src"
BUILD_DIR="site"
WEBPSH="/your/webp/convert/path"
COMMIT_COMMENT="`echo "Memory" && free -h | head -2 | awk  '{print $(NF-5)"," $(NF-4)"," $(NF-3)}' | column -t -s ","`"

export DENO_INSTALL="/home/$USER/.deno"
export PATH="$DENO_INSTALL/bin:$PATH"

cd "$SRC_DIR" || exit
ls "$SRC_DIR/.git" || git init || exit
git add . || exit

git commit -m "$COMMIT_COMMENT"

if [ $? -eq 0 ]; then
  $WEBPSH
  cd $LUME_DIR || exit
  # deno task lume --dest=$BUILD_DIR
  deno task lume --dest=$BUILD_DIR > /dev/null 2>&1
else
  exit 1
fi

В общем, я хотел реализовать это максимально коротким кодом, поэтому получилось так.
Ну, COMMIT_COMMENT выглядит немного запутанно, но это просто для развлечения...

Сначала я записывал время с помощью date, но потом подумал: «Разве это не лишнее, если я могу проверить это с помощью git log?»
(Может быть, даже стоит добавить какой-нибудь случайный ASCII-арт...)

Скрипт, показанный выше, запускается каждые 5 минут с помощью cron.

Давайте посмотрим на возвращаемые значения Git

В общем, похоже, что возвращаемое значение git add . в Git не может обнаруживать изменения, например, возвращаемое значение, когда git init не был выполнен:

alleycat:[haturatu]:~/git/gittest$ ls -la
合計 8
drwxr-xr-x  2 haturatu haturatu 4096 10月 14 01:08 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
alleycat:[haturatu]:~/git/gittest$ git add .
fatal: not a git repository (or any of the parent directories): .git
alleycat:[haturatu]:~/git/gittest$ echo $?
128

Это 128.
Теперь давайте создадим или удалим файл после выполнения git init.

alleycat:[haturatu]:~/git/gittest$ ls -la
合計 12
drwxr-xr-x  3 haturatu haturatu 4096 10月 14 01:11 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
drwxr-xr-x  7 haturatu haturatu 4096 10月 14 01:11 .git
alleycat:[haturatu]:~/git/gittest$ git add .
alleycat:[haturatu]:~/git/gittest$ echo $?
0
alleycat:[haturatu]:~/git/gittest$ touch test
alleycat:[haturatu]:~/git/gittest$ ls -la
合計 12
drwxr-xr-x  3 haturatu haturatu 4096 10月 14 01:11 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
drwxr-xr-x  7 haturatu haturatu 4096 10月 14 01:11 .git
-rw-r--r--  1 haturatu haturatu    0 10月 14 01:11 test
alleycat:[haturatu]:~/git/gittest$ git add .
alleycat:[haturatu]:~/git/gittest$ echo $?
0

Таким образом, git add . не изменяет возвращаемое значение, поэтому изменения не могут быть обнаружены.
Тогда давайте посмотрим на возвращаемое значение при выполнении commit.

alleycat:[haturatu]:~/git/gittest$ ls -la
合計 12
drwxr-xr-x  3 haturatu haturatu 4096 10月 14 01:11 .
drwxr-xr-x 72 haturatu haturatu 4096 10月 14 01:08 ..
drwxr-xr-x  7 haturatu haturatu 4096 10月 14 01:11 .git
-rw-r--r--  1 haturatu haturatu    0 10月 14 01:11 test
alleycat:[haturatu]:~/git/gittest$ git commit -m "nyaa"
[master (root-commit) 60bed93] nyaa
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test
alleycat:[haturatu]:~/git/gittest$ echo $?
0
alleycat:[haturatu]:~/git/gittest$ git commit -m "nyan nyan"
On branch master
nothing to commit, working tree clean
alleycat:[haturatu]:~/git/gittest$ echo $?
1

Похоже, что если изменений нет, возвращается 1.
Таким образом, мы можем определить это по этому возвращаемому значению, и остальное уже не проблема.

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

Итак, мне кажется, что этот метод управления изменениями может быть полезен и в других случаях.
Однако я постоянно ищу более простой, легкий и рекурсивный способ мониторинга изменений в каталогах, что кажется простым, но на самом деле нет.
В случае с командой find, это очень мощная команда, поэтому запускать ее для мониторинга изменений довольно утомительно (интересно, используется ли она как внутренняя команда Git?).
Если приходится писать собственный код для мониторинга изменений, то нужно также включать проверку для исключаемых каталогов. В этом отношении мониторинг изменений с помощью Git очень удобен, так как ненужные каталоги, которые не нужно отслеживать, можно просто указать в .gitignore, и они будут фактически исключены из мониторинга.

В этом отношении Git очень хорош.
Однако, поскольку Git хранит кэш в .git, он может быть не очень подходящим для мониторинга каталогов с очень большими файлами. Поэтому можно было бы хешировать каждый файл, сохранять его как текстовый файл в /tmp, затем выполнять diff и, если возвращается значение, указывающее на разницу, запускать процесс обработки изменений.
Такое, возможно, можно было бы сделать.
Однако, если добавлять код для исключения файлов, сортировать перед diff и так далее, это может стать довольно сложным, и я бы не хотел этого делать.

Пока писал, подумал...

На самом деле, вместо запуска find, можно просто вывести ls -laR в /tmp и получить разницу.
Но почему Git кажется более легковесным...? Если начать разбираться в этом, то придется углубляться в деконструкцию Git, так что на сегодня хватит.

До новых встреч!

Related Posts