mirror of
https://github.com/getcargohq/cargo-skills.git
synced 2026-09-14 19:17:15 +08:00
53a1a86a7f
* Add cargo-hosting capability skill
Document the `hosting` CLI domain (apps, workers, deployments) as a
dedicated capability skill, following the one-skill-per-CLI-domain
convention.
- cargo-hosting/SKILL.md: init -> create -> deploy -> promote lifecycle
for Vite SPA apps (*.cargo.app) and edge workers, with critical rules
and async polling.
- references/examples/{apps,workers,deployments}.md, response-shapes.md,
troubleshooting.md.
- Register in the cargo router (skill count 10->11, capability table row,
recap, removed hosting from the no-skill-yet table, synced frontmatter
count) and bump cargo 1.4.0 -> 1.5.0.
- README capability table + skill count (11 -> 12).
- CHANGELOG entries for cargo-hosting 1.0.0 and cargo 1.5.0.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
* Add hosting terms to glossary
Add app/appUuid, deployment/deploymentUuid, hosting, worker/workerUuid
entries to cargo/references/glossary.md, and correct the capability-skill
domain list (was missing content and hosting). CHANGELOG updated.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
* Pin hosting response shapes from backend types
Replace inferred shapes/caveats in cargo-hosting with the authoritative
App/Worker/Deployment structures: kind app/worker discriminant,
promotedDeployment, chargedUntil, and the deployment status enum
(pending/building/success/error/cancelled, terminal at the last three).
Polling + build-failure docs now cite the real status/errorMessage/
buildLogS3Filename fields, and a critical rule notes monthly hosting
credits per resource.
https://claude.ai/code/session_018LeD9abpD7LYBhGGkDxSup
---------
Co-authored-by: Claude <noreply@anthropic.com>
2.2 KiB
2.2 KiB
Deployment examples
A deployment is one build+upload of a local source directory to an app or worker. Two facts drive everything below:
- A deployment belongs to exactly one app or worker —
--app-uuidand--worker-uuidare mutually exclusive. - Building is not promoting.
deployment createbuilds; the live URL only moves when youdeployment promote.
Create a deployment
# App: backend runs `npm ci && vite build` in a sandbox
cargo-ai hosting deployment create --app-uuid <app-uuid> --source ./my-app
# Worker: backend bundles the entrypoint
cargo-ai hosting deployment create --worker-uuid <worker-uuid> --source ./my-worker
--sourceis the package root (wherepackage.jsonlives), not a pre-builtdist/. The build happens server-side.- Default ignore list:
node_modules,dist,build,.git,.next. Override the whole list with--ignore:
cargo-ai hosting deployment create --app-uuid <app-uuid> --source ./my-app \
--ignore "node_modules,dist,build,.git,.next,coverage,.turbo"
Poll the build, then promote
# Builds are async — poll until the status field is terminal
cargo-ai hosting deployment get <deployment-uuid>
# when terminal (built/succeeded), promote:
cargo-ai hosting deployment promote --uuid <deployment-uuid>
If the build failed, inspect the deployment record for the error and fix the source before re-running deployment create. See ../response-shapes.md for the fields to check.
List deployment history
cargo-ai hosting deployment list --app-uuid <app-uuid> # newest first
cargo-ai hosting deployment list --worker-uuid <worker-uuid>
See what's currently live
cargo-ai hosting deployment get-promoted --app-uuid <app-uuid>
cargo-ai hosting deployment get-promoted --worker-uuid <worker-uuid>
Roll back to a previous deployment
Promotion just points the live URL at a deployment, so rolling back is promoting an older one — no rebuild needed.
# 1. Find the deployment you want to go back to
cargo-ai hosting deployment list --app-uuid <app-uuid>
# 2. Promote it
cargo-ai hosting deployment promote --uuid <older-deployment-uuid>
# 3. Verify
cargo-ai hosting deployment get-promoted --app-uuid <app-uuid>