hosting
POST /v1/sites/{siteId}/deployments/{deploymentId}/redeploy
Roll back by re-publishing an earlier deploy's commit.
Санҷиши ҳаққоният
Kaliti API-ро ҳамчун рамзи доранда (bearer token) фиристед. Калит бояд дорои иҷозати hosting.deploy.manage бошад; калиди бидуни он бо хатои 403 рад карда мешавад, на 404.
Ин нуқтаи поёнӣ ягон рақами мушаххаси созмонро талаб намекунад. Калиди шумо аллакай созмонеро, ки ба он тааллуқ дорад, муайян мекунад ва ҷавоб ба он маҳдуд карда мешавад.
Санҷидан
Ҳар чизро дар қаavски кунҷӣ бо қиматҳои худ ва ҷойи нигоҳдорандаи калидро бо калима аз панели идоракунии худ иваз кунед.
curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/deployments/{deploymentId}/redeploy \
-H "Authorization: Bearer zdk_live_…"Воarid шудаед? Консоли API дар панели идоракунии шумо рақами мушаххаси ташкилоти воқеӣ ва калиди худро пур мекунад ва дархостро бар зидди API-и фаъол иҷро мекунад, то шумо посухи воқеиро бубинед. Ин нуқтаи ниҳоиро дар консоли API кушоед
Тафсилот
Rollback is a forward deploy of the recorded commit, not a provider-side pointer move — a provider rollback promotes a deployment that provider still holds, so it silently does nothing once that has expired, behaves differently on each backend, and leaves our history naming a commit the site is not on. A deployment with no recorded commit returns `UNPROCESSABLE_ENTITY`. Requires `hosting.deploy.manage`.
Параметрҳо
| Ном | Намуд | Талаб карда мешавад | Ин чӣ аст |
|---|---|---|---|
siteId (path) | Uuid | Бале | Site ID (UUIDv7). |
deploymentId (path) | Uuid | Бале | Deployment ID (UUIDv7). |
Ҷавоб
| Ном | Намуд | Талаб карда мешавад | Ин чӣ аст |
|---|---|---|---|
id | Uuid | Бале | UUIDv7 identifier — sortable by creation time (docs/02 §8). |
site_id | Uuid | Бале | UUIDv7 identifier — sortable by creation time (docs/02 §8). |
target | DeployTarget | Бале | Where the site is published from. `fleet` is our own managed fleet; the rest are managed edge hosts, deployed to from a pooled account of ours or the customer's own connected on… |
status | DeployStatus | Бале | `idle` means the site has never been deployed. It is reported, never stored — a stored idle would be a second way to say "no deployments" that could contradict the first. |
trigger | DeployTrigger | Бале | What caused the deploy. Stored because `requested_by` cannot answer it for a push — the actor there is a webhook delivery, not a person. |
repo | object | Бале | — |
branch | object | Бале | — |
commit | object | Бале | — |
commit_message | object | Бале | — |
live_url | object | Бале | — |
message | object | Бале | Why it failed, else null. Rendered to the customer verbatim. |
requested_by | string | Бале | — |
created_at | string | Бале | — |
started_at | object | Бале | — |
finished_at | object | Бале | — |
log | string | Бале | The build log, one timestamped line per step. Truncated from the FRONT when long — the end of a build log is where the failure is. |
Хатоҳое, ки ин нуқтаи ниҳоӣ метавонад баргардонад
401 · 403 · 404 · 409 · 422 · 429 · 503