@dmgnr/kuber 1.2.1 → 1.3.0

package/README.md

@@ -66,6 +66,8 @@ bun run index.ts exec app sh
 bun run index.ts start
 bun run index.ts stop
 bun run index.ts restart
+bun run index.ts rollback
+bun run index.ts fuck app
 bun run index.ts db ls
 bun run index.ts s3 ls
 bun run index.ts s3 creds app
@@ -93,13 +95,15 @@ For a permanent setup, write the generated script to a file and source it from y
 
 ## Commands
 
-- `up`: build images if needed, render manifests, apply them, restart deployments whose image content changed, and wait for rollout
-- `start`: same as `up` but skips image builds
+- `up`: build images if needed, pin matching registry digests, render manifests, apply them, and wait for rollout
+- `start`: same as `up` but resolves the currently published image digests instead of building
 - `stop`: scale managed deployments to zero
 - `restart`: roll out a restart across managed deployments
+- `rollback` (alias `fuck`): roll one deployment back to its previous release, or all managed deployments when no name is given
 - `down`: delete managed resources while keeping ingress, PVCs, managed databases, and managed S3 storage
 - `down -f`: also delete ingress, PVCs, managed database and S3 resources, and the namespace
-- `ps`: list deployments in the current project namespace
+- `ps`: print an ANSI tree of the current project namespace, hiding stopped deployments by default
+- `ps -a`: include stopped deployments and stale ReplicaSets in the tree
 - `logs [deployment]`: print logs for one deployment or all managed deployments
 - `logs -f [deployment]`: follow logs continuously
 - `exec <deployment> <command...>`: execute a command inside a running deployment pod
@@ -366,7 +370,32 @@ Precedence:
 
 ## Building
 
-Image builds and image-digest checks run through the selected SSH builder. If a pushed image has the same content fingerprint as the existing registry image, `up` does not restart that deployment.
+Image builds run through the selected SSH builder. After a push, the registry's
+manifest digest is captured and embedded into the rendered Deployment as an
+immutable `:latest@sha256:...` reference, so a changed image naturally triggers
+a rollout (there is no separate "restart changed deployments" step). `start` and
+`export` look up the currently published digest without rebuilding, and fail if
+a buildable service has no published image yet.
+
+## Rollback
+
+`kuber rollback [deployment]` (alias `fuck`) rewinds managed Deployments to the
+previous release. ReplicaSets carry a `deployment.kubernetes.io/revision`
+annotation, and rollback restores the complete pod template from the next-older
+ReplicaSet via a JSON Patch, then waits for the rollout to complete. With no
+argument every managed Deployment is rolled back; pass a deployment name to
+target a single one.
+
+Notes and limitations:
+
+- Kubernetes only keeps its most recent ReplicaSets, so an older release may no
+  longer be reachable after enough successful rollouts/rollbacks.
+- Rollback restores the pod template (including image and environment), not live
+  Secret, ConfigMap, PVC, database, or S3 state.
+- A later `kuber up` or `kuber start` re-resolves `:latest` and returns the
+  Deployment to the current desired state anyway, so rollback is the right tool
+  for responding to a bad deploy, not for permanently pinning an old version.
+- Rollback only considers Deployments managed by kuber (`app.kubernetes.io/managed-by=kuber`).
 
 To build distributable binaries: