Как настроить автоматическую подкачку коммитов?

Question

[Александр]

Привет.

Подскажите пож-ста, как сделать автоматическое скачивание новых коммитов?

Пример:
Есть 2 сервера тестовый / боевой и 2 ветки dev / master соответственно. Работаем с dev, делаем коммиты, сливаем dev с master, и нужно чтобы на боевом сразу появились изменения. С помощью чего это настраивается?

В гугле не нашел ничего.

Answer 1

[askhat]

Git Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git...

Хуки бывают клиентскими и серверными. Могут выполняться до и после практически любого действия с репозиторием. Вам, скорее всего, нужен хук post receive.

Хук сам по себе просто скрипт на любом языке поддерживаемом ОС, при запуске он получит в аргументы некоторую информацию о событии, на основе которых вы сможете валидировать операцию и выполнить любые другие действия.

Answer 2

[Дмитрий Свиридов]

Судя по тегу "gitlab", тебе надо на сервер установить gitlab-runner, настроить его, а в GitLab в настройках проекта его включить для проекта. В корне репозитория положить файл .gitlab-ci.yml с примерно таким содержанием:

stages:
  - deploy

deploy:
  stage: deploy
  environment:
    name: master
  script:
  - cd /app
  - git reset --hard
  - git pull origin master
  - source ./env/bin/activate
  - pip install -r ./requirements.txt
  - python3 manage.py migrate
  - python3 manage.py collectstatic --noinput
  - sudo supervisorctl restart ololo.backend
  - python3 manage.py clearcache
  - python3 manage.py warmcache
  only:
  - master
  tags:
  - linux
  - shell

Тогда, при попадании коммита в master, раннер на сервере будет "узнавать" об этом и выполнять команды, описанные в секции script.
Мой пример не совсем production-ready, так сказать, потому что состоит из одного шага - deploy. Если по-хорошему делать, то перед ним, как минимум, должен быть шаг запуска тестов, без успешного прохождения которых шаг deploy выполняться не будет. Это дает хоть какую-то гарантию, что код, попавший в master, будет работать на сервере. Имей это в виду)

Comments

[Александр]

Спасибо

[Георг Гаал]

У меня есть внезапное откровение...

- git reset --hard
- git pull origin master

Это не нужно, т.к. гитлаб раннер ВСЕГДА скачивает все содержимое репозитория (регулируется отдельным параметром в gitlab-ci.yml). Поэтому второй раз скачивать ничего не надо )

[Дмитрий Свиридов]

Георг Гаал, да, но скачивает он в свою папку в /home/gitlab-runner/builds/<рандомный набор букв (возможно, часть хеша коммита>. А у меня проект в совсем другой директории и вообще не в хомяке.

[Георг Гаал]

Ну, так сделайте cp . /dst/path ...зачем клонить повторно - неясно

[Дмитрий Свиридов]

Георг Гаал, ну, предположим, не клонить повторно, а затянуть изменения.

1. А там будут файлы, которые не под гитом? Конфиги и т.п.?
   
2. По какому принципу узнавать рандомное название папки в builds, чтобы выполнить cp?
   

[Георг Гаал]

1. Как сделаешь - так и будет.
2. В текущем каталоге при запуске пайплайна )

Answer 3

[Владимир]

https://docs.gitlab.com/ee/ci/

Answer 4

[coderisimo]

Есть такая штука ХУКИ
Есть собственные плюшки для подобного на bitbucket. Суть похожа, они легко настраиваются и работают