CI: Build and Deploy Your Own Code Beside the Chat
A walkthrough of the CI app: linked repositories, pipelines found in the repo, Kubernetes job stages, logs and cancel, run records and masked secrets.
Yantra Team2 min read
On this page
Writing the code is one job. Building it, testing it and putting it on a cluster is another. CI runs that second job for your own code, in a panel you can ask questions of while it runs.
Open it
Pick CI in the apps launcher, or open /c/<chat-id>/ci. It is available from a brand-new chat. CI brings its own agent, so the panel is the one thing on screen: the main chat column folds away while it is open. The launcher's starter prompt shows the kind of request it is for: "Run the tests on every push to main and deploy when they pass."
Point it at a repository
CI lists the repositories linked to your workspace and their branches. It can also discover the pipelines a repository already carries, so you start from what the project defines instead of rewriting it.
Run a stage
Each pipeline stage runs as its own Kubernetes job. A stage can be a stage script from the repository, a raw script, or a plug-in step:
- A Helm step installs or upgrades a release from a chart repository, an
oci://reference or a chart directory in the repository, with values files and--setoverrides. It can wait until the release is ready and roll back when an upgrade fails. - A Kubernetes step applies manifests or kustomizations, sets Deployment images and waits for their rollouts. A server-side dry run validates every change without making it.
- A commands step runs any other shell commands the stage needs.
Kubernetes and Helm steps act on the cluster in a kubeconfig you keep as a secret. Settings that the kubeconfig or a default already covers stay behind Show more on the job form until you need them. Save a job to run it again, and delete it when it is no longer needed.
Watch, read logs, cancel
Every job has a status, its logs and a cancel. List the jobs that are running and the runs that came before. A job has a hard ceiling of three hours, so a stuck build is stopped rather than left running.
Secrets stay out of the logs
Secret values are masked in job logs. The masking also catches the forms a script might print them in by accident: base64, URL-encoded and JSON-escaped. Finished jobs, with their pods, logs and the run's secret, are removed after an hour by default and never kept longer than a day. The run record keeps what you need after that.
From chat
- "Run the tests on every push to main and deploy when they pass."
- "Show me the logs of the last CI run."
- "Cancel the build that is running now."
- "Deploy the web chart to staging with Helm and wait until it is ready."
What it is not
Writing or fixing the code is Codezen, which ends in a pull request for CI to build. Databases, auth servers and model servers come from Workspaces; see Spin up a database from a chat message. Recurring automations that are not about your code, like a morning inbox summary, belong in Workflow Studio.