BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
Приветствую! Возникла потребность настроить CI/CD на GitLab с помощью runner После того как раннер зарегистрирован и активен, и настроено соединение с сервером по ssh ключам, деплои проходят норм, но спустя время (пару дней), Jobs`ы начинают сваливаться в ошибку
Код
fatal: git fetch-pack: expected shallow list
fatal: The remote end hung up unexpectedly
и если последовать примеру ее решения на BitrixVM 7.5.x, которое заключается в удалении и установки GIT
Код
sudo yum remove git
то вместе с git зависимостями будут удалены пакеты
bitrix-env etckeeper perl-Git
в следствии чего мы теряем виртуальную машину.... которую затем восстановить предложенным способом, лично у меня не получилось (она установилась, но критический функционал в ней по добавлению сайтов к примеру не заработал)
Может кто то сталкивался с такой проблемой, как ее можно решить что бы деплой заработал, т.е как безопасно обновить git на BitrixVM 7.5.x ?
Деплой организован с помощью rsync т.е по сути то git на сервере с VM в принципе не нужен и никак не используется... но почему то GitLab матюкается что версия старая...
написал: Нужные команды, типа git pull / git clone и прочие можно добавить в сам скрипт. Они вполне нормально работают с git из centos 7
не проверил сразу.. джобы то теперь завершаются без ошибок, но файлы измененные почему то не прилетают на сервер.. т.е изменений нет на сервере после отработки джобы с этой переменной GIT_STRATEGY: none почему так, как пофиксить?
red_eye, в какой скрипт? дело в том что на сервере я не использую гит, для того что бы подтягивать изменения из репозитария. Изменения прилетают на сервер по rsync. Это сделано для того что бы мне не пришлось учитывать что админы сайта могут менять файлы через "эрмитаж" например.
написал: И очень зря, при взломе гит очень помогает.
не понятно просто как мне не затирать изменения которые клиент будет через эрмитаж вносить в конфигурациях компонентов или создании новых разделов, подразделов и страниц сайта... по этому и отказался от git... т.е от такого
И кстати не понятно зачем мне добавлять в секцию script команды гита если как я и описал выше, на сервере не используется git для файлов сайта... Вот это момент я вообще не понял, вы предлагает от rsync отказаться или одновременно с ним использовать эти команды (какие кстати?)?
Вячеслав Докукин написал: зачем мне добавлять в секцию script команды гита если как я и описал выше, на сервере не используется git для файлов сайта
Вы прочитали документацию? По умолчанию, раннер стягивает изменения из гита c помощью гит команд. В скриншоте ошибки ясно видно, что не проходит гит команда (git fetch-pack), которая у вас не используется в списке команд, потому что и так задана через GIT_STRATEGY. Переменная в вашем примере не указана, поэтому используется значение по умолчанию.
Сейчас вы отключили это поведение через GIT_STRATEGY: none. Следовательно нужные команды нужно прописать вручную. Какие именно, вам виднее.
Судя по коду в текущем примере, раннер скачивает изменения из гита для веток stage / main в некую временную директорию, а потом из этой директории через rsync загружает изменения на дев / прод. Так что гит команды у вас вполне используются.
Если вы по прежнему хотите делать это через rsync, то просто cоздайте свою временную директорию в которую склонируйте гит и пропишите что-нибудь в этом роде
Код
cd /home/gitlab-runner/path/to/tmp/dir
git checkout main
git pull <remote> main
Добавлять в начало блока scripts. Для stage естественно заменить main на stage Указать свой remote вместо <remote>. По умолчанию origin