<span id="build-pipeline" />

# Конвейер сборки

Сборки выполняются на узлах сборки Lizard — **вам не нужен Docker локально**. При развёртывании платформа по заданному порядку решает, как превратить ваш исходный код в образ контейнера, а затем запускает этот образ в изолированном поде. Не каждый [контейнер как сервис](https://lizard.build/blog/container-as-a-service) собирает образ за вас; в блоге сравниваются три формы, в которых встречается эта категория.

<span id="build-decision-order" />

## Порядок выбора стратегии сборки

Платформа выбирает ровно одну стратегию сборки, в таком порядке:

1. **Синтезированный Dockerfile** — если на сервисе заданы `buildCommand` и/или `startCommand` (или переданы через `lizard up --build-command` / `--start-command`), Lizard генерирует Dockerfile из этих команд. lizardpack не вызывается.
2. **Dockerfile из репозитория (как есть)** — если на сервисе задан `dockerfilePath`, используется тот Dockerfile из вашего репозитория без изменений.
3. **Автоопределение lizardpack** — иначе платформа клонирует ваш исходный код и запускает **lizardpack**, свой генератор Dockerfile / buildpack.

<span id="lizardpack-auto-detect" />

### Автоопределение lizardpack

lizardpack анализирует ваш репозиторий и собирает оптимизированный многостадийный образ. Поддерживаемые стеки, проверяемые в таком порядке:

**Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static**

См. [Руководства по фреймворкам](https://lizard.build/ru/docs/framework-guides) для продакшн-скриптов, адаптеров, путей вывода и портов. Определение использует файлы проекта и зависимости; репозиторий, подходящий под несколько провайдеров, следует этому порядку.

На этом пути:

- Если в репозитории есть `Dockerfile` **и** в нём есть реальный шаг сборки (строка `RUN <package-manager>`, а не только `COPY dist/`), он используется как есть.
- Иначе lizardpack генерирует Dockerfile за вас.
- **Команда запуска** определяется автоматически: строка `Procfile` `web:` (Python/Ruby) или `package.json` `scripts.start` (Node) подхватывается автоматически. Для точной строки, которую хотят Django, Flask и FastAPI, см. [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting).
- **Порт** выводится из `EXPOSE`, значений фреймворка по умолчанию или явной переменной окружения `PORT`.

> **Подвох:** Dockerfile, который только копирует предварительно собранные артефакты (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) **без** шага сборки `RUN`, считается неполным и регенерируется lizardpack. Добавьте реальный шаг сборки или задайте `dockerfilePath` для принудительного использования как есть.

<span id="what-triggers-a-rebuild" />

## Что вызывает пересборку

| Действие | Пересобирает? |
|----------|---------------|
| `git push` в отслеживаемую ветку | ✅ через вебхук GitHub |
| `lizard redeploy` / `lizard up` | ✅ явно |
| Изменение переменных `VITE_*` или `NEXT_PUBLIC_*` | ✅ значения времени сборки запекаются в образ |
| `service set` полей сборки (`repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath`, `rootDirectory`) | ✅ автопересборка |
| `service set` полей только времени выполнения (`startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns`) | ❌ запустите `lizard redeploy` для применения |
| Любое другое изменение переменной окружения / секрета | ❌ применяется при быстром перезапуске (без пересборки) |

> **Не дублируйте сборку.** После `service set`, меняющего поле сборки, пересборка запускается автоматически — не ставьте в цепочку `lizard redeploy` после этого, иначе поставите в очередь вторую избыточную сборку.

<span id="watching-a-build" />

## Наблюдение за сборкой

Логи сборки стримятся во время `lizard up`. Для любого сервиса:

```bash
lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status
```

Если сборка упала, прочитайте `lizard logs --build`, устраните причину (в репозитории или скорректировав `buildCommand` / `startCommand` через `lizard service set`), затем `lizard redeploy`.

<span id="runtime-notes" />

## Примечания к рантайму

- **Нет Docker `HEALTHCHECK`.** Рантайм не запускает цикл healthcheck Docker, поэтому директивы `HEALTHCHECK` игнорируются. Lizard выполняет TCP-пробирование вашего порта вместо этого (пропускается в [режиме воркера](https://lizard.build/ru/docs/deploy/workers)).
- **Не пишите Dockerfile без нужды.** lizardpack автоопределяет большинство стеков — попробуйте сначала задеплоить, и добавляйте Dockerfile (или задавайте `dockerfilePath`) только если автосборка не подходит.

<span id="build-configuration-reference" />

## Справочник по конфигурации сборки

| Поле | Описание |
|------|----------|
| `buildCommand` | Команда сборки вашего приложения → принудительно использует путь **синтезированного Dockerfile** |
| `startCommand` | Команда запуска приложения во время выполнения |
| `preDeployCommand` | Выполняется один раз перед каждым деплоем (например, миграции БД) |
| `dockerfilePath` | Путь к Dockerfile в репозитории для использования **как есть** |
| `rootDirectory` | Поддиректория для сборки (монорепозитории) |
| `watchPatterns` | Передеплой только при изменении соответствующих путей |
| `containerPort` | TCP-порт, который слушает приложение (по умолчанию `3000`; `0` = [воркер](https://lizard.build/ru/docs/deploy/workers)) |

Любое из этих полей можно задать через `lizard service set <svc> --set <field>=<value>`. См. [`lizard service`](https://lizard.build/ru/docs/cli/service).