使用 Zinnector® 进行部署：关联、检查、推送

当项目在本地运行后，只需四个命令即可将其部署到 Zinn Digital® 托管平台上的线上站点：登录、将项目关联到托管槽位、查看预检结果以及推送。本文将逐一介绍每个命令、其输出内容以及后续会用到的命令——重新部署、部署历史记录和构建日志。

使用 API 密钥登录

在控制面板的设置 → API 密钥下创建密钥，然后执行：

zinnector login

密钥在提示符处输入——绝不会在命令行中直接接收，因此它不会留在您的 Shell 历史记录或进程列表中。在 CI 环境中，可以通过管道传入：echo "$ZINN_API_KEY" | zinnector login --profile ci，或者设置 ZINNECTOR_TOKEN 并完全跳过 login。密钥在存储前会经过验证，并以文件模式 600 进行存储。zinnector whoami --scopes 可显示您登录的组织以及该密钥所具备的权限；沙盒密钥会被标记出来。

将项目关联到槽位

zinnector link                                   # 从列表中选取站点
zinnector link example.com --repo acme/site --branch main

link 会将站点的 ID 写入 zinnector.json，并且除非传入 --no-repo，否则它会将项目的 Git 远程仓库连接到平台上的站点，以便推送时直接部署。请将 zinnector.json 提交到版本库：克隆该仓库的同事无需额外获知即可直接部署到同一位置。它不包含任何机密信息。

查看预检结果

zinnector check

这是该 CLI 存在的初衷命令。它会将您的项目与即将部署的目标槽位进行比对，并输出每一处不匹配之处——以及未能完成比对的每一项：

• PHP 版本，主版本差异被定级为高危（high），因为这往往必然导致站点崩溃；次版本差异则定级较低，因为将所有问题都定为严重级别会导致人们忽略警告。
• 槽位是否能切换至您构建时使用的版本、槽位的 PHP 是否已终止支持，以及机器是否已应用该版本还是仅收到指令。
• 您的项目大小和文件数量与槽位实际剩余的磁盘及 inode 余量对比——WordPress 文件树可能在远未达到磁盘上限时就已经耗尽文件数配额。
• 两端的 WordPress 版本、槽位是否已完成配置，以及是否已连接仓库以供推送。

它仅作警告，绝不阻断。每一项检查结果均可通过 zinnector push --force 予以覆盖，因为您比检查工具更了解自己的站点。无法完成的比对会被报告为未知（unknown），绝不会当作通过处理，且摘要中始终会注明此类项目的数量。默认情况下，本地 PHP 版本为 zinnector.json 中声明的版本；使用 --probe 则会启动本地运行时并直接对其进行检测。--strict 也会在存在未知项时返回非零退出代码，这正是 CI 门禁所需要的机制。

推送

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 在平台上针对您自己的账户运行，因此它可以查看相同的部署历史记录和日志。从项目内部运行时，它会发送项目的结构特征——目录名称、版本以及站点 ID，绝不会发送文件内容。

相关内容

• 快速入门 · 本地开发 · 命令参考 · 问题排查