---
title: "2026-08-07 Release workflow validity review"
description: "Validated a two-stage Nx release-PR and exact-SHA post-merge delivery design for mono."
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.

# 2026-08-07 Release workflow validity review

## Work Done

- Inspected all current `virdx/mono` GitHub Actions, Nx release groups, Pixi version actions, release-tagged projects, conda recipes, and the existing dashboard-api Tekton PipelineRun shell script; made no mono repository edits.
- Validated that release-branch pushes and pull requests must use a GitHub App installation token rather than `GITHUB_TOKEN` if ordinary `push`/`pull_request` workflows and post-merge automation are expected to run.
- Designed post-merge detection around manifest version changes between `github.event.before` and the immutable `github.sha`, yielding one project/version record per independent release rather than a shared version.
- Confirmed Tekton should receive the full merge SHA as its `revision` parameter; the existing script's `main` revision is race-prone.

## Lessons Learned: Pitfalls

- The existing `release-preview.yml` uses a repository-wide “any `*@*` tag exists” first-release test. That becomes incorrect as soon as one independently versioned project has a tag while another does not; bootstrap tags or per-project handling are required.
- `vxdata-sdk` currently emits a `vxdata-schemas` subpackage at the SDK version, so its recipe and upload behavior violate independent schema/SDK versioning. A split recipe, or separate schema-version input plus SDK-only artifact upload, is prerequisite to safe automation.
- Git tags produced by `GITHUB_TOKEN` do not trigger tag-push workflows, and release PR commits made with it suppress downstream workflow events. Branch filters prevent an App-token tag push from recursively invoking a main-branch workflow.
- GitHub Actions has no checked-in authentication route to the Tekton cluster. Exact-SHA YAML alone is insufficient; a least-privilege service account on a self-hosted runner or authenticated trigger is required.

## Lessons Learned: Improvements

- Add a canonical release metadata file mapping each project to its manifest, artifact type, platforms, conda recipe or image Dockerfile, and Tekton parameters; use it for both release detection and delivery matrices.
- Document idempotency rules: verify an existing `project@version` tag points at the same merge SHA, and never silently overwrite immutable package/image versions.

Source: https://docs.virdx.dev/knowledge/inbox/2026-08-07-infrastructure-release-workflow-validity-review/index.mdx