---
title: "vxData independent release automation"
description: "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."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# vxData independent release automation

Status: **draft PR open** ([`virdx/mono#323`](https://github.com/virdx/mono/pull/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](/knowledge/wiki/workstreams/infrastructure/sops/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](/knowledge/wiki/workstreams/infrastructure/sops/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](/knowledge/wiki/workstreams/infrastructure/sops/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 `COPY`s `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](/knowledge/wiki/workstreams/infrastructure/sops/vxdata-sdk-and-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](/knowledge/wiki/workstreams/infrastructure/sops/vxdata-db-restore-and-cluster-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.

## Further reading

A same-day research pass
(`inbox/2026-08-07-infrastructure-agentic-monorepo-delivery-research.md`)
surveyed current (2025–2026) external practice for agentic-monorepo delivery
(isolated worktrees, GitHub merge queues + `merge_group`, SLSA/Sigstore
attestations, Changesets/release-please, Argo Rollouts canaries, OpenAI/
OpenTelemetry eval instrumentation) — useful background if this project's
scope grows beyond vxData into a general monorepo release policy, but none
of it has been adopted yet; treat it as reading material, not current state.

## 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`

Source: https://docs.virdx.dev/knowledge/wiki/workstreams/infrastructure/projects/vxdata-independent-release-automation/index.mdx