Как настроить очень простое развертывание с помощью Gitlab CI runner?

71
10

Я хотел бы автоматически развернуть новую работу из моего репозитория Gitlab на живой веб-сайт, запущенный на производственном сервере. Живой сайт - это клон репозитория GIT в live.

Мои вопросы:

    каждый раз, когда происходит "сборка", бегун, похоже, клонирует мое репо заново, в ~/builds/... Это обязательное поведение? Все, что я думаю, я действительно хочу, это git pull внутри моего каталога веб-сайта.

    если он действительно должен клонировать репо каждый раз, почему он не git reset его? По крайней мере, это спасло бы тонну полосы пропускания с течением времени, не так ли?

    как запустить мой deploy.sh который находится в корне репозитория? Я получаю эту ошибку в моей сборке gitlab.com: bash: line 23: deploy.sh: command not found

Мой .gitlab-ci.yml:

deploy_to_production:
script:
- deploy.sh
only:
- live
tags:
- prod

Детали

Чтобы сделать это, я хочу, чтобы запустить простой скрипт, который я написал (deploy.sh) на сервере, когда я нажимаю на определенную ветвь моего репо (в live ветке, в моем случае). Этот сценарий оболочки находится в моем репозитории GIT, рядом с моим .gitlab-ci.yml.

Скрипт в основном просто выполняет git reset, fetch и pull, обновляя версию выпуска, с тем, что в репозитории.

Я установил многостраничный "shell" на свой сервер и подключил его к gitlab.com, где я могу видеть его активным.

В целом, я лаяю неправильное дерево? Должен ли я изменить свой deploy.sh чтобы он не выполнял git checkout новой работы, а скорее использовал cp или, возможно, rsync чтобы переместить новый код с ~/builds/... на веб-сайт?

спросил(а) 2016-05-16T01:26:00+03:00 4 года, 4 месяца назад
1
Решение
70

В: Является ли клонирование обязательным поведением?

Насколько я знаю, это связано с тем, что в процессе сборки вы работаете с кодом.

Если это не ваш случай, и вы только хотите "сообщить производственному серверу", чтобы вытащить код из своего репо, тогда, возможно, вы можете использовать другой подход и вместо этого использовать webhook. GitLab сделает HTTP-запрос на ваш сервер и передаст информацию о событии (push, merge и т.д.) В формате JSON. Затем скрипт-получатель проанализирует его и примет решение о том, следует ли делать git pull.

Если перед развертыванием у вас есть другие задачи для выполнения кода во время процесса сборки, тогда да, измените стратегию и используйте код, который бегун уже проверил для вас. Я бы, вероятно, попытался каким-то образом изменить атомное изменение (rsyncing в live-каталог оставит ваше приложение в некотором неопределенном состоянии, когда он будет запущен, и в беспорядке, если он по какой-то причине сбой), например, имея код в реальном времени каталог, который имеет символическую привязку. Сценарий развертывания затем скопирует новый каталог кода в конечный пункт назначения, внесем необходимые корректировки и изменит цель символической ссылки из старого живого каталога в новый.

В: Если на самом деле нужно клонировать репо каждый раз, почему он не перезагружает его?

Это больше вопрос для разработчиков. Любой другой ответ будет просто домыслом.

В: Как запустить мой deploy.sh, который находится в корне репозитория?

Если в сценарии deploy.sh установлен исполняемый бит, используйте ./deploy.sh, в противном случае bash deploy.sh.

ответил(а) 2016-05-16T12:31:00+03:00 4 года, 4 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема