Inspected virdx/mono at 4e99bef on the clean feat/vxdata-release-automation branch; made no repository edits.
Designed a release-state-driven PR bot, checked-in canonical OpenAPI snapshot/diff, and post-merge schema/SDK publication plus API image rebuild flow.
Identified the required propagation matrix: schema -> schema + SDK versions and API rebuild; SDK -> SDK; API OpenAPI contract -> API + SDK; API implementation-only -> API.
Lessons Learned: Pitfalls
packages/vxdata-sdk/conda.recipe/recipe.yaml currently builds vxdata-schemas as a same-version subpackage and exact-pins it. This makes independent versions impossible until the recipe is split.
No release tags currently exist, so Nx’s first-release fallback cannot safely establish per-project release baselines. A checked-in release SHA or explicit bootstrap tags are required.
API image builds hardcode main, and a schema-only rebuild would overwrite/reuse the same API version tag. Builds need an exact revision and immutable composite API/schema tag.
GitHub Actions currently has no visible cluster authentication path for submitting the Tekton PipelineRun; automation needs a narrowly scoped self-hosted runner/service account or another authenticated trigger.
Lessons Learned: Improvements
Document the ownership and credentials for automated Tekton submissions and the immutable vxData image-tag/deployment-pin convention.
Document whether OpenAPI changes are the complete definition of an SDK-relevant API contract; non-OpenAPI transport/semantic changes require an explicit override label or release-plan file.
