Added
helix ci init generates your deploy workflow
Run it from the project root and it asks which CI service you use (GitHub Actions today) and how deploys should be triggered: on demand, on every merge, or a two-target strategy with an approval gate before production. It writes the workflow files and prints the one-time GitHub setup. Every target must already have a projectId and workspaceId, so the command refuses, naming the config file to fix, rather than generate a workflow that provisions a new project on every run. Pass --provider and --strategy to run it without a terminal.
Read the docs →
Added
helix deploy --wait waits for the rollout
helix deploy returns as soon as the upload is accepted. Add --wait and it keeps polling until the platform finishes rolling out: the command exits 0 once the deployment is ready, and exits 1 with the build errors printed when it fails, so a CI job fails for the right reason. --wait-interval and --wait-timeout tune the polling.
Read the docs →
Added
TRAY_CLI_TOKEN for headless use
Set the TRAY_CLI_TOKEN environment variable to a Tray API user token and every command uses it instead of a saved helix login session. Nothing is written to disk and the token is never refreshed. It is how the generated workflows authenticate, and the token reaches everything in its workspace, so give the API user the lowest role that can still deploy.
Read the docs →
