|
Publish / Gate: k8s deploy e2e (push) Failing after 3s
Details
Deploy Test / Run deploy test suite (push) Failing after 0s
Details
Publish / Build and publish (push) Has been skipped
Details
K8s Deployment Control Test / Run deployment control suite on kind/k8s (push) Failing after 0s
Details
Webapp Test / Run webapp test suite (push) Failing after 0s
Details
Smoke Test / Run basic test suite (push) Failing after 0s
Details
Lint Checks / Run linter (push) Failing after 0s
Details
K8s Deploy Test / Run deploy test suite on kind/k8s (push) Failing after 0s
Details
Closes so-p3p: - New spec key `caddy-ingress-image`: on fresh install, deploys Caddy with this image; on subsequent `deployment start`, patches the running Caddy Deployment if the image differs. Defaults to the manifest's hardcoded image when absent - When the spec key is absent, SO does **not** touch a running Caddy — avoids silently reverting an image set out-of-band (ansible playbook, another deployment's spec) - `strategy: Recreate` on the Caddy Deployment manifest (required — hostPort 80/443 deadlocks rolling updates) - Reconcile runs under both `--perform-cluster-management` and the default `--skip-cluster-management` (it's a k8s-API patch, not a cluster-lifecycle op) - Image template by container name rather than string match, so the spec override wins regardless of what the shipped manifest hardcodes - Cluster-scoped caveat documented: `caddy-system` is shared across deployments, so the last `deployment start` that sets the key wins for everyone |
||
|---|---|---|
| .. | ||
| images | ||
| CONTRIBUTING.md | ||
| README.md | ||
| adding-a-new-stack.md | ||
| cli.md | ||
| deployment_patterns.md | ||
| docker-compose-deployment.md | ||
| fetching-containers.md | ||
| gitea-with-laconicd-fixturenet.md | ||
| helm-chart-generation.md | ||
| k8s-deployment-enhancements.md | ||
| laconicd-with-console.md | ||
| release-process.md | ||
| spec.md | ||
| webapp.md | ||
README.md
Stack Orchestrator
Here you will find information about the design of stack orchestrator, contributing to it, and deploying services/applications that combine two or more "stacks".
Most "stacks" contain their own README which has plenty of information on deploying, but stacks can be combined in a variety of ways which are document here, for example: