Automate publishing the opt-in VST packs (CI), like the venue content-packs workflow

[mhglover]

Automate publishing the opt-in VST packs (CI), like the venue content-packs workflow

Problem

The opt-in VST-pack system shipped (rig #55, core #1025) but the three packs are not published: data/vst_packs.json still holds placeholders (bytes: 0, all-zero sha) for mac/win/linux, so the runtime gate correctly keeps the "download a simulated rig" path hidden. There is no automation to build and publish them — unlike career venue packs, which have .github/workflows/content-packs.yml in core (build → publish release → open a manifest-bump PR).

We need the equivalent for VST packs so a maintainer can publish (and re-version) them from the Actions tab instead of hand-running the tool and hand-editing hashes.

Why it's not a copy of the venue workflow

The venue workflow is trivial because everything is in core — media, tool, release, and manifest — so GITHUB_TOKEN suffices. The VST pieces are split across two repos:

Piece	Lives in
Fat .vst3 binaries (the pack source)	rig repo (committed by build-*-vst3.yml)
content_packs.build_vst_pack (the slicer + --vst CLI)	core (got-feedBack/feedBack)
data/vst_packs.json (manifest to bump)	rig repo
Release URLs the manifest currently points at	core (…/feedBack/releases/download/vst-<plat>-v1/…)

Because the binaries live in rig but the releases are configured for core, publishing forces exactly one cross-repo write no matter where the workflow runs — and cross-repo writes need a PAT, not the free GITHUB_TOKEN.

Proposed fix (recommended): host the VST packs as rig-repo releases

The binaries already live in rig, so hosting the releases there too collapses the cross-repo problem — the same rationale that put venue packs + their workflow in core ("host where the media and manifest live"). Everything becomes same-repo, GITHUB_TOKEN-only, no PAT.

Add .github/workflows/vst-packs.yml in the rig repo (workflow_dispatch, inputs version default 1), which:

1. Checks out the rig repo (fat .vst3 bundles present in-tree).
2. Fetches tools/content_packs.py from core at a pinned ref (public, read-only — curl the raw file or a sparse checkout).
3. Runs python content_packs.py <vst_root> --vst --version N --publish --repo <this-rig-repo> --manifest /tmp/vst-manifest.json → builds the three per-platform slices and uploads them as immutable vst-<plat>-v<N> releases in the rig repo.
4. Rewrites data/vst_packs.json url/sha256/bytes from the manifest and opens a bump PR (peter-evans/create-pull-request), mirroring content-packs.yml.

Small prerequisite changes:

• core tools/content_packs.py: add a --repo CLI flag (default got-feedBack/feedBack, so the venue path is unchanged) and thread it to both call sites in the --vst branch — the upload target and the URL written into the manifest:

  # today both default to REPO (core); they MUST use the same repo:
  _publish_release(vst_tag(plat, v), zip_path, title, notes, repo=args.repo)
  url = vst_url(plat, v, repo=args.repo)

  This is the load-bearing detail: the asset is downloaded from whatever vst_url() emits into data/vst_packs.json, so if --repo reaches _publish_release but not vst_url (or vice-versa), the manifest points where the asset isn't and every client download 404s. _publish_release/vst_url already accept repo=; only main()'s --vst branch passes neither today.
• rig data/vst_packs.json: the three URLs are rewritten from the tool's manifest on each publish, so once --repo reaches vst_url they self-correct to the chosen host. Still flip the committed placeholders got-feedBack/feedBack/releases/… → got-feedBack/feedBack-plugin-rig-builder/releases/… up front so the intended download location is correct in-tree even before the first run.

Alternative: keep releases in core (needs a PAT)

Run the workflow in either repo but publish to core; whichever repo it runs from, it needs a PAT with write scope on the other repo (release-upload on core, or the manifest-bump PR on rig) stored as a repo secret. More moving parts and a maintainer secret to rotate — only worth it if there's a reason to keep all release assets under core.

Acceptance criteria

• A maintainer can publish/re-version all three VST packs from the Actions tab with GITHUB_TOKEN only (recommended path).
• Publishing produces immutable vst-<plat>-v<N> releases and opens a vst_packs.json bump PR with real sha256/bytes.
• The URL written into vst_packs.json resolves to the release the workflow actually uploaded to (same host/tag/asset) — i.e. --repo reached both _publish_release and vst_url. Guard it with a test asserting vst_url(plat, v, repo=r) matches the upload target for the same r.
• After merge, the rig download prompt goes live (the bytes>0 gate flips) and a client download sha-verifies end-to-end.
• The venue content-packs.yml path is unaffected by the --repo flag.

Related

• rig feat: opt-in per-platform VST pack (download + slicing + first-run prompt) #55 (opt-in VST download), core #1025 (build_vst_pack + --vst), rig test(vst): make the VST-pack download test runnable + add a test CI #57 (VST download test + CI).
• Prior art: core .github/workflows/content-packs.yml (venue packs).