Staging & Production

After onboarding, every deploy of the service publishes its OpenAPI specs and rebuilds the docs. Nobody runs anything by hand: the two workflows created during onboarding start when the deployed image tag changes.

Deploying to Staging

1. Update the pointer. The image tag in deployment/regions/us-east-1/nvq2/values.yaml changes and is pushed to main. This is what deploys the service to staging, and it is also what starts docs-staging.yaml.
2. Publish the specs. The workflow copies the specs from the deployed commit into platform-content-registry as a new version, and points the service's stagingVersion to it.
3. Build the staging docs. The workflow starts a staging build of docs-kaltura-com, which deploys to docs.nvq2.ovp.kaltura.com/next.
4. Check quality. In parallel, the workflow runs the plugin's quality skill in non-interactive mode. If the score is below the threshold, it opens a PR in the service repo with the recommended fixes. A sensitive-data blocker fails the run.

Deploying to Production

Production works like staging, with two differences:

• No quality check. Quality is handled on staging, before the version reaches production.
• Security check only. The workflow runs the sensitive-data check, and only if it passes does it publish the specs, set productionVersion, and start the production docs build to docs.kaltura.com automatically.