构建方案(Dockerfile 与 zbpack)
Git 服务在 Zenavo 的构建机上用 BuildKit 构建。服务如何构建称为它的构建计划,部署前可以预览。
Dockerfile
如果服务的根目录中有 Dockerfile,会直接使用它。添加服务时可以在 高级设置 → Dockerfile 路径 中设置其他路径,之后也可以在服务的 设置 标签页 → Dockerfile 中修改(例如 deploy/api.Dockerfile,相对于根目录)。
zbpack
没有 Dockerfile 时,zbpack 会识别语言和框架并生成一个。它支持 Node.js、Bun、Deno、Python、Go、PHP、Ruby、Java、Rust、.NET、静态网站等。仓库中有 zbpack.json 文件,或者服务有 ZBPACK_* 环境变量(用于配置 zbpack,例如构建和启动命令)时,也会使用 zbpack。
zbpack 构建的镜像监听 8080 端口,所以除非你另外设置,服务的 HTTP 端口就是 8080。
zbpack 选项
在服务的 设置 标签页 → 构建 → zbpack 选项 中,每行填写一个 KEY=value:
- 以
ZBPACK_开头的键,例如ZBPACK_BUILD_COMMAND=npm run build或ZBPACK_START_COMMAND=node dist/server.js,会作为变量传给 zbpack。它们优先于 变量 标签页中的ZBPACK_*变量。 - 其他键会写入根目录中的
zbpack.<service>.json,效果与仓库中的zbpack.json文件相同。以 JSON 形式写的值({…}、[…]、true或false)会保留其类型。
只要设置了任何 zbpack 选项,服务就会用 zbpack 构建,即使根目录中有 Dockerfile。
构建参数
在 设置 标签页 → 构建 → 构建参数 中,每行填写一个 KEY=value。每一项都会传给构建:你自己的 Dockerfile 用同名的 ARG 行读取;在 zbpack 生成的 Dockerfile 中,Zenavo 会在每个执行命令的阶段加上这行 ARG。变量 标签页中的变量不会自动传给构建;要使用某个变量,用 ${KEY} 引用它,例如 VITE_API_URL=${API_URL}。
构建日志中会隐藏这些值,但如果声明它的阶段在最终镜像中,就可以从镜像的历史中读到;构建过程如果把它写进了输出,也能从输出中读到。只有在构建确实需要时,才把密钥作为构建参数传入。
根目录
在 monorepo 中,添加服务时或之后在 设置 标签页中,把 根目录 设为服务所在的文件夹,例如 /apps/api。构建以该文件夹作为上下文,Dockerfile 和 zbpack 都是如此。它必须在仓库内部。
要只在该文件夹有改动时重新部署,请设置服务的监听路径。
在 manifest 中
设置 标签页保存的是项目 manifest 中服务 source 的这些字段;你也可以在导出或导入的 manifest 中设置它们:
"source": {
"git": "https://github.com/acme/mono",
"ref": "main",
"context": "apps/api",
"dockerfile": "Dockerfile",
"build_args": { "NODE_ENV": "production" },
"zbpack": { "ZBPACK_BUILD_COMMAND": "npm run build" },
"auto_deploy": true,
"watch_paths": ["apps/api/", "packages/shared/"]
}构建计划预览
预览会克隆分支,报告构建将使用什么,但不会构建或运行任何东西:
| 行 | 示例 |
|---|---|
| 提供方 | Dockerfile、go、nodejs、python 等 |
| 版本 | Go 版本 1.26.1,Node.js 版本 22 |
| 端口 | 来自 Dockerfile 的 EXPOSE,zbpack 则为 8080 |
限制
构建共享 Zenavo 的构建机,构建机繁忙时会排队。一次构建(包括克隆)最长可以运行套餐的单次构建上限:Free 15 分钟,Dev 30 分钟,Pro、Team 和企业版 60 分钟;其中克隆本身最多 10 分钟。达到上限的构建会被中止,部署失败,已用的构建分钟数照常计入。各套餐的构建分钟数见用量与账单。