LINUX.ORG.RU

Скрипт для билда: обновление во время билда

 


1

2

Делаю скрипт, который будет дёргаться при изменении в репозитории. Смысл в том, чтобы сделать pull, собрать новую версию, установить куда положено. Как обрабатывать ситуацию, когда событие произошло во время билда? Второй билд запускать не хочу. Собственно хочу, чтобы билд дошёл до конца, а потом запустился ещё раз, сбилдив на сей раз последнюю версию.

Пока делаю примерно так:

if [ -e build-in-progress ]; then
  touch rebuild
  exit
fi
touch build-in-progress
...
if [ -e rebuild ]; then
  rm rebuild
  exec $*
fi
rm build-in-progress

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

Есть ли какой-нибудь способ сделать это всё по уму, который будет работать железобетонно?

★★★★★

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

но как-то всё это ненадёжно

0 -> [build-in-progress] -> +rebuild -> +build-in-progress -> [rebuild] -> -rebuild -> 0 \
0 -> [build-in-progress] -> +rebuild -> +build-in-progress -> [rebuild] -> -rebuild -> 0 \
0 -> [build-in-progress] -> +rebuild -> +build-in-progress -> [rebuild] -> -rebuild -> 0 \
...

То ли я чего то не понимаю.

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

Не понял эту диаграмму.

Зато теперь я понял. Рекурсивно вызывать скрипт пока не удалится build-in-progress в первом скрипте. Но не проще ли использовать while [ -e build-in-progress ] и sleep для ожидания.

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

Можно и так, без разницы. Проблема в том, что если скрипт вызовется два раза одновременно, то у обоих скриптов [ -e build-in-progress ] вернёт false, потом они оба создадут файл и оба пойдут делать билд, что приведёт к какой-нибудь ерунде. То же с rebuild может быть. Можно там обгородить всё через flock, но как-то это всё сложно выходит, больше кода с этими блокировками, чем осмысленного кода. Может есть какой-нибудь приём.

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

Ты пользуешь touch, а надо логирование: в один файл собираемую в данный момент версию, во второй - последнюю известную версию.

PS: А в третий - последнюю собранную версию.

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

в один файл..., во второй

Или один лог с полным состоянием репа: current, last, status.

Deleted
()

Задача: в каждый момент времени вести только один процесс сборки.

Варианты решения:

  1. скрипт сборки перед запуском проверяет файл блокировки

  2. запускать только один процесс сборки (хоть через init/systemd), пусть он сам чекает событие когда не занят сборкой

Мне кажется способ 1 лучше, т.к. по событию можно и убить сборку, результаты которой точно не нужны. Но 2й может быть проще.

legolegs ★★★★★
()

Очередь событий сделай(хоть через mkfifo). Но тут сборщик мониторить придётся на предмет не сдох ли он

Deleted
()

По уму - это взять CI нормальный, а не велосипедить. А вообще надёжный лок на шелле делаться flock/lockf’ом.

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

Брать здоровенную бандуру для того, что делается маленьким скриптом за десять минут - полный бред. flock не поможет, слишком много плясок. Я поменял подход.

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

Делаю один flock на весь скрипт, вторые запуски и тд висят в очереди, а потом быстро отработают, т.к. есть проверка на то, что pull ничего не вытащил.

Legioner ★★★★★
() автор топика
Последнее исправление: Legioner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.