zel publish

Check, build and deploy — the three you run in that order anyway.

zel publish

What it is

zel check → zel build → zel deploy, stopping at the first failure.

It does nothing the three cannot, and it takes no arguments they do not. Everything about what gets published lives in zel.toml:

content = "docs"

[build]
target = "static"

[deploy]
provider = "netlify"
site = "acme-docs"

With that file, publishing your documentation is one word. Without it, zel publish needs the same flags the three commands would, and you may as well run them.

Why it exists

zel deploy already checks and builds before uploading, so the two overlap. The distinction is where the intent lives.

zel deploy netlify docs says put this folder on Netlify now — a decision made at the terminal. zel publish says do the thing this repository is configured to do, and the configuration is reviewed, committed and the same for everyone. The second is what belongs in a pipeline, in a Makefile, and in the sentence "how do I ship the docs?" that a new colleague asks.

What each step contributes

1. 1

   Check

   Under a second. A broken internal link stops the publish here rather than shipping a 404 — and rather than wasting the four minutes the build would take before failing on the same thing.

2. 2

   Build

   Produces whatever the target says. static for a CDN, image for a registry.

3. 3

   Deploy

   The provider decides the target, so there is nothing to keep in step by hand.

Until it lands

The three commands, in order:

zel check docs && \
zel build docs --out dist && \
netlify deploy --prod --dir dist

&& rather than ; matters: it is the whole of what publish adds.

See also

• zel deploy — where the provider logic lives
• zel ship — the same idea, starting from another tool's docs
• zel.toml — what makes this one word