vxData independent release automation

In-progress redesign of mono's release automation so vxdata-schemas, vxdata-sdk, and vxdata-api version and publish independently, with exact-SHA Tekton delivery. Draft PR mono#323.

Status: draft PR open (virdx/mono#323), not merged/enabled. This consolidates a same-day research → audit → design → validation → implementation chain of inbox/ sessions (2026-08-07) into one place, since a future agent picking this up shouldn’t have to reconstruct the reasoning from five separate recaps.

Problem

vxdata-schemas, vxdata-sdk, and vxdata-api (mono) are supposed to be independently versioned, but the mechanics coupled them:

packages/vxdata-sdk/conda.recipe/recipe.yaml built vxdata-schemas as a same-version subpackage (pin_subpackage('vxdata-schemas', exact=True) — see Conda packaging and releases for the general multi-output-recipe pattern this exploited), so schemas could never carry a version independent of the SDK.
API image builds hardcoded main as the Tekton revision, which is race-prone, and a schema-only rebuild would overwrite/reuse the same API image tag.
No release tags exist yet in mono, so Nx Release’s “first release” fallback (release-preview.yml’s repo-wide “any *@* tag exists” check) breaks as soon as one independently-versioned project has a tag and another doesn’t.
Root AGENTS.md and the infrastructure conda-release SOP describe contradictory operative release mechanisms (Nx Release vs. the actual manual dispatch pattern) — read both, trust neither alone; verify against the workflow YAML.

Design (validated, then implemented)

Propagation matrix:

Change	Propagates to
schema change	schema version and SDK version, API rebuild
SDK-only change	SDK version only
API OpenAPI contract change	API and SDK versions
API implementation-only change	API version only

Mechanics:

Release-state-driven PR bot (rolling GitHub App-authored release PR), replacing the prior duplicate manual schemas/SDK release workflows.
Checked-in canonical OpenAPI snapshot + deterministic diff to detect SDK-relevant contract changes (a non-OpenAPI transport/semantic change still needs an explicit override label or release-plan file — OpenAPI diff alone is not a complete definition of “API contract change”).
Post-merge package publishing in dependency order (schemas before SDK).
Split the SDK conda recipe from the schemas recipe — supersedes the same-version-subpackage pattern for this specific package (the general multi-output pattern in Conda packaging and releases is still correct for packages that should share a version).
API image requests use the exact release merge SHA, not main.
API tagging is deliberately deferred to a trusted callback after verified image publication — enqueueing a Tekton build is not build success, so tagging immediately after enqueue would produce false releases.

Open infrastructure gaps (block enabling this)

GitHub Actions has no checked-in authentication path to submit a Tekton PipelineRun. A least-privilege service account on a self-hosted runner, or another authenticated trigger, is required — this is a prerequisite, not something the release-automation PR itself can solve. Related, but a different failure mode: even a Kubernetes ServiceAccount cannot create a PipelineRun in tekton-builds today, because of how the virdx.dev/requestor label is derived — see the “ServiceAccount cannot create a PipelineRun” gotcha in Executing jobs on the cluster. Both must be fixed before any GitHub-Actions-triggered cluster build works.
Git tags/commits made with a plain GITHUB_TOKEN don’t trigger on: push/tag-push workflows — a GitHub App installation token is required for release-branch pushes/PRs and any post-merge automation to actually run. (Same trap conda-packaging-and-releases.md already flags for vimgx’s legacy bump_version.yaml pattern — a recurring footgun.)
workflow_dispatch on a credentialed workflow is unsafe without a trusted-ref guard (dispatch can select an arbitrary ref); the shipped workflow removes dispatch and narrows the App-token permissions instead.

Other drift found during the audit (not yet fixed, not part of PR #323)

The mono-wide automation audit that fed this project also found unrelated concrete drift worth knowing about before touching adjacent CI/build config:

apps/docs’s Containerfile COPYs apps/inference/README.md, which has since been removed from the repo — a latent build break waiting for a cache miss.
dashboard-api has duplicate version sources that interact incorrectly with the shared Pixi-version GitHub Action.
vxdata-explorer’s conda recipe constraints exclude the current 2.1 SDK/ schema versions (see vxData SDK + schema model for the current 2.1.0 surface) — it will fail to solve until bumped.
apps/docs/services/deploying_dashboard_vxdata.md has stale in-repo manifest paths and a misspelled build-script path — don’t treat it as authoritative for current deployment state; cross-check vxData production DB restore + cluster storage gotchas instead.
Some GitHub Actions workflows reference build matrices they don’t actually declare, and some projects are missing test-path triggers entirely — project-by-project CI coverage in mono is uneven; don’t assume a project has CI parity with its neighbors without checking.

Implementation notes (PR #323)

Eight planner tests validate the propagation matrix.
A first review round caught that tracking only component src/ paths misses packaging metadata and Docker runtime inputs — release planners need the full artifact input boundary.
A local inherited MPLBACKEND=module://matplotlib_inline.backend_inline caused unrelated vxa-sdk test-collection failures unless overridden with MPLBACKEND=Agg — not a regression in the PR, but worth knowing before chasing a red CI run against this branch.

Source recaps

inbox/2026-08-07-infrastructure-agentic-monorepo-delivery-research.md
inbox/2026-08-07-infrastructure-mono-automation-audit.md
inbox/2026-08-07-infrastructure-release-workflow-validity-review.md
inbox/2026-08-07-infrastructure-vxdata-independent-release-draft.md
inbox/2026-08-07-infrastructure-vxdata-release-automation-pr.md