Автоматический деплой по push
Сервис можно разворачивать не кнопкой, а по коммиту: вы делаете git push в рабочую ветку, платформа собирает новую версию и заменяет ею работающую. Настройка сводится к одному действию: добавить вебхук в репозитории.
Вебхук представляет собой уведомление, которое git-сервис сам отправляет по указанному адресу, когда в репозитории что-то происходит. Платформа принимает такое уведомление, проверяет его подлинность и ставит сборку в очередь.
Что нужно сделать
Настройка живёт на вкладке «Автоматическое развёртывание» экрана сервиса. Вкладка появляется после первого успешного развёртывания: до него разворачивать нечего.
- Проверьте переключатель. Автоматическое развёртывание включено по умолчанию.
- Скопируйте
Webhook URLиSecret. Панель показывает их тут же, у каждого сервиса значения свои. - Добавьте вебхук в репозитории. Кнопка «Открыть вебхуки репозитория» ведёт сразу на нужную страницу, а какие поля заполнять, указано в таблице ниже.
- Сделайте push в ветку сервиса и убедитесь, что в ленте развёртываний появилась новая сборка.
Ветка задаётся при создании сервиса. Push в остальные ветки платформа принимает, но игнорирует.
Настройка у провайдера
| Провайдер | Где добавить | Что заполнить |
|---|---|---|
| GitHub | Settings → Webhooks → Add webhook | Payload URL = ваш URL, Secret = секрет, событие «Just the push event». Content type подходит любой из двух |
| GitLab | Settings → Webhooks | URL, секрет в поле «Secret token», триггер «Push events» |
| Gitea / Forgejo | Settings → Webhooks → Gitea | URL, секрет в поле «Secret», Content-Type application/json, событие Push |
| Bitbucket | Repository settings → Webhooks | Только URL: Bitbucket не подписывает доставки, поэтому секрет уже встроен в сам URL. Триггер «Repository push» |
| GitFlic | Настройки проекта → Вебхуки → Создать | URL, секрет в поле «Секрет», событие только «Обновление ветки» |
| GitVerse | Настройки проекта → Вебхуки → Добавить вебхук | URL, метод POST, формат application/json, событие Push. Секрет вставляется в поле «Заголовок Authorization» как есть, без Bearer и других префиксов: с префиксом проверка не пройдёт |
| SourceCraft | Файл .sourcecraft/webhooks.yaml в репозитории | Готовый файл показан в панели, закоммитьте его в основную ветку. Затем откройте страницу вебхука в SourceCraft, скопируйте ключ подписи и вставьте его в панель. Ключ генерирует сам SourceCraft, поэтому шага здесь два |
Свой git-сервер или CI
Если репозиторий лежит на собственном сервере (bare-репозиторий по SSH) или уведомления шлёт сборочный конвейер, готового вебхука нет. Для таких случаев панель показывает триггер: отдельный URL и токен, который передаётся в заголовке X-Hostim-Token.
Есть два готовых варианта, в обоих значения уже подставлены:
- Свой SSH-git сервер. Скрипт
hooks/post-receive. Положите его в репозиторий на сервере и сделайте исполняемым (chmod +x). Он выполнится при каждом push и вызовет триггер, если push пришёл в нужную ветку. - CI/CD. Однострочный вызов
curlв конце конвейера. Токен положите в секреты CI (в примере он называетсяHOSTIM_DEPLOY_TOKEN), в открытый конфиг его класть не нужно.
Триггер не разбирает содержимое запроса, он проверяет только токен. Ветку можно не передавать, тогда берётся ветка сервиса.
Когда push не запускает деплой
Платформа отвечает провайдеру успехом (иначе он пометит доставку проваленной и начнёт повторы), но сборку не ставит в четырёх случаях:
| Условие | Что происходит | Что делать |
|---|---|---|
| Автоматическое развёртывание выключено | Доставка принята, сборки нет | Включите переключатель |
| Push пришёл не в ветку сервиса | Пропуск | Проверьте, какая ветка указана у сервиса |
| Сервис остановлен | Пропуск | Чужой push не отменяет вашу остановку. Нажмите «Запустить», затем разверните свежий код вручную |
| Коммит уже собран | Пропуск | Так и задумано: это повторная доставка или push без изменений |
Ручное развёртывание этих ограничений не знает: кнопка разворачивает сервис всегда.
Что именно соберётся
Собирается текущее состояние ветки на момент начала сборки, а не тот коммит, который был указан в уведомлении. Отсюда два следствия:
- Несколько коммитов подряд дадут одну сборку последнего состояния, а не сборку на каждый коммит.
- Если push пришёл во время идущей сборки, очередь из сборок не копится. Сразу после текущей соберётся один раз самая свежая версия, промежуточные пропускаются. В панели это видно по метке «новые коммиты в очереди».
Отдельно стоит случай технических работ на платформе: push при них не теряется, после снятия ограничения соберётся последняя версия ветки.
Как выключить
Переключатель на вкладке «Автоматическое развёртывание». При выключении вебхук в репозитории менять не нужно: доставки продолжают приниматься, но сборка не запускается. Разворачивать сервис можно вручную.
Если сборка не запускается
Начните со списка доставок у провайдера (у GitHub это Recent Deliveries, у остальных есть аналогичный раздел). В нём виден код ответа платформы:
| Ответ | Причина | Решение |
|---|---|---|
401 | Секрет не совпал | Скопируйте секрет из панели заново, целиком и без лишних символов. У GitVerse проверьте, что перед значением нет префикса |
404 | Адрес неверный или сервис удалён | Сверьте Webhook URL с панелью |
200, сборки нет | Сработало одно из условий выше | Причина указана в теле ответа: autodeploy_off, stopped, branch или unchanged |
| Доставок нет вообще | Вебхук не создан или подписан не на то событие | Проверьте, что вебхук активен и событие у него push |
Частые ошибки
| Симптом | Причина | Решение |
|---|---|---|
| Вкладки настройки нет | Сервис ещё ни разу не разворачивался | Разверните его вручную один раз |
| На один push запускаются две сборки | Настроены и вебхук провайдера, и триггер из CI | Оставьте что-то одно |
| Собралось не то, что коммитили | Берётся состояние ветки на момент старта сборки | Убедитесь, что нужный коммит уже в ветке сервиса, и разверните ещё раз |
| Сборка запустилась, но упала | К вебхуку это не относится, своё дело он сделал | Разбирайте по логам сборки, см. «Почему падает деплой» |