Как только проект запустится локально, всего четыре команды перенесут его на рабочий сайт на хостинге Zinn Digital®: вход в систему, привязка проекта к слоту хостинга, предварительная проверка и отправка (push). В этой статье подробно рассматривается каждая из них, выводимые ими данные, а также команды, которые понадобятся вам впоследствии: повторное развертывание, история развертываний и журналы сборки.
Вход с помощью ключа API
Создайте ключ в панели управления в разделе Настройки → Ключи API, затем выполните:
zinnector login
Ключ вводится по запросу в строке — он никогда не принимается в качестве аргумента командной строки, поэтому он не попадет в историю вашей командной оболочки или в список процессов. В среде CI передайте его через конвейер: echo "$ZINN_API_KEY" | zinnector login --profile ci, либо задайте переменную ZINNECTOR_TOKEN и полностью пропустите команду login. Ключ проверяется перед сохранением и записывается с правами доступа к файлу 600. Команда zinnector whoami --scopes показывает, в какую организацию вы вошли и какими разрешениями обладает ключ; ключ для тестовой среды (sandbox) помечается соответствующим образом.
Привязка проекта к слоту
zinnector link # выбор сайта из списка
zinnector link example.com --repo acme/site --branch main
Команда link записывает идентификатор сайта в файл zinnector.json и, если вы не передали флаг --no-repo, подключает удаленный git-репозиторий проекта к сайту на платформе, чтобы отправка кода запускала его развертывание. Зафиксируйте файл zinnector.json в коммите: коллега, клонировавший репозиторий, сможет выполнять развертывание в то же самое место без дополнительных инструкций. В этом файле нет никаких секретных данных.
Предварительная проверка
zinnector check
Именно ради этой команды и существует CLI. Она сравнивает ваш проект со слотом, на который он будет развернут, и выводит каждое несоответствие, а также каждое сравнение, которое не удалось выполнить:
- Версия PHP, при этом расхождение в мажорной версии классифицируется как высокий уровень риска, так как это гарантированно нарушает работу сайта, а расхождение в минорной версии — как более низкий, поскольку маркировка всего подряд как критической ошибки приучает людей игнорировать предупреждения.
- Может ли слот переключиться на версию, на которой выполнялась сборка, наступил ли у версии PHP на слоте конец жизненного цикла, и действительно ли машина применила версию или ей была лишь отправлена команда.
- Размер и количество файлов вашего проекта относительно запаса места на диске и свободных inode, фактически оставшихся на слоте: дерево WordPress может исчерпать лимит файлов, даже не приблизившись к ограничению по объему диска.
- Версии WordPress с каждой стороны, завершилась ли подготовка слота и подключен ли репозиторий для отправки.
Команда предупреждает, но никогда не блокирует. Любой результат проверки можно переопределить с помощью zinnector push --force, так как вам известны особенности вашего сайта, о которых средство проверки не знает. Сравнение, которое не удалось произвести, отмечается как неизвестно (unknown), но никогда как пройденное (pass), а в сводке всегда указывается их количество. По умолчанию локальной версией PHP считается та, которая объявлена в zinnector.json; флаг --probe запускает локальную среду выполнения и определяет версию напрямую. Флаг --strict возвращает ненулевой код завершения даже при наличии неизвестных параметров, что как раз необходимо для барьеров качества в CI.
Отправка (Push)
zinnector push
Команда push выполняет предварительную проверку, отправляет ваши коммиты, инициирует развертывание и отслеживает его до завершения, выводя окончательный статус и развернутый коммит. Флаг --dry-run выполняет все действия, кроме самого развертывания; --no-wait инициирует процесс и завершает работу команды; --no-git развертывает то, что уже есть на платформе, без отправки кода. Если развернутый коммит не совпадает с тем, который только что был отправлен, команда сообщит об этом.
Если что-то пошло не так
zinnector deploys example.com # история развертываний: статус, коммит, инициатор, сообщение
zinnector logs example.com --build # журнал сборки самого последнего развертывания
zinnector logs example.com --error # журнал ошибок сайта
zinnector deploy example.com # повторное развертывание того, что уже есть на платформе
zinnector ai "why is my deploy failing?"
Инструмент zinnector ai выполняется на платформе в контексте вашей учетной записи, поэтому он может просматривать ту же историю развертываний и журналы. Из директории проекта он передает структуру проекта (имена каталогов, версии и идентификатор сайта) и никогда не отправляет содержимое файлов.
См. также