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

Длительный хук git post-receive вызывает тайм-аут

У меня есть обработчик post-receive, написанный на python, основная функция которого - развернуть обновленную ветку. Он клонирует репо в новый каталог и запускает такие настройки среды, как npm install и создание / заполнение виртуальных объектов. Это выполняется на стороне сервера и запускается при нажатии на git-http-backend (проксируется за nginx).

Это развертывание занимает некоторое время - несколько минут. Это кажется слишком большим для git, из чего следует, что The remote end hung up unexpectedly и это обеспечивает error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out.

я нашел этот ответ который пришел к выводу, что git сдается, если какое-то время нет вывода на stdout. Автор сообщения «исправил» проблему, увеличив вывод спама из сценария на стандартный вывод. Для меня это не идеально. Есть ли способ настроить git, чтобы он не сдавался после короткого перерыва?

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

На самом деле я даже поступаете правильно? Каков «правильный» способ иметь долго работающие скрипты, которые запускаются в результате перехватов git, когда пользователь должен видеть обратную связь (т.е. вывод / результаты)?

РЕДАКТИРОВАТЬ: Дальнейшее расследование показало fastcgi_read_timeout настройка для nginx. Его можно увеличить для увеличения времени ожидания, но это не решает мою проблему. После перенаправления stdout в файл я обнаружил, что мой скрипт на самом деле завершается довольно быстро. Но по какой-то причине бэкэнд git не проходит через stdout, когда он есть, а затем зависает навсегда. Кроме того, перенаправление stdout устраняет зависание. В чем дело?

EDIT2: дальнейшая отладка показала, что сценарий не работает при обращении к тому же серверу git для клонирования другого репо (сервер также возвращает 504). Это похоже на то, что git-http-backend может обрабатывать только один запрос за раз? Это не так, потому что post-receive все еще в разработке, когда этот новый clone запрос приходит? Если так, это кажется тревожным ограничением! Есть ли способ поддерживать одновременные запросы к git-http-backend?