From a template to a running service
The golden paths this platform offers, what a scaffold actually writes, and how to see the difference between "nothing customised" and "customised".
A template is a whole component: source, a Dockerfile where the build needs one,
its openchoreo/ manifests, and enough of an application to be worth deploying.
Four golden paths, each with what it produces.
The templates →
Preview before you write anything
The scaffold page renders exactly what would be committed, for the parameters you give it, before anything is created.
The preview updates. Nothing is written until you say so.
Open one and change a parameter →The interesting comparison is between two previews of the same template:
| nothing customised | the template as it ships |
| with traits chosen | 0 added · 3 changed · 4 untouched |
That second line is the point. A scaffold that silently rewrites files is a scaffold you cannot review; one that says which files it touched, and how, is a diff you can read before it exists.
What happens after
- 1
A repository, with a first commit
Created in Gitea, with the webhook already wired.
- 2
Components and bindings applied
From the
openchoreo/directory the template wrote. This is the same manifest sync that runs on every push, so there is no special first-time path to get wrong. - 3
A build, automatically
The push that created the repository is a push, so it builds.
- 4
It appears in the root environment
autoDeploy cuts a release and binds it. Which environment that is depends on the project's DeploymentPipeline —
platform-servicesroots at development,applicationsat staging.
kubectl patch on a Component does not survive. Manifest sync applies whatever
the repository holds, so a cluster-only edit is reverted by the next push — and
worse, it breaks the build that push triggers. Edit
apps/*/openchoreo/component*.yaml instead.
Adding a component to a project that already exists
The same path, and the interesting state is what it looks like mid-flight: a component that exists in staging and not yet in production is not a fault, it is a promotion that has not happened.
A gap in a row is a component that has not reached that environment yet.
Every project, every environment →A promotion of a brand-new component is the case most likely to be refused on capacity, because it is the only kind that adds requests rather than replacing them. The preview says so before you press it.