CI: Dispatch release events to downstream consumer repos

[edvilme]

Summary

• replace the previous downstream sync workflow with a release-triggered repository_dispatch fan-out workflow
• dispatch a shared-package-release event to each consumer repository listed in the workflow
• add a consumer workflow template document with payload contract and starter receiver workflow
• rename the workflow file to downstream-release-dispatch.yml to match behavior

Important setup requirement

Each consumer repository must add and maintain its own workflow yml file that listens for:

• repository_dispatch
• event type: shared-package-release

Without a repo-local receiver workflow, dispatch events from this repo will be sent but no update automation will run in that consumer repo.

Validation

• workflow and docs lint/diagnostics pass locally

[rchiodo]

The core wiring gap (target branch never created in the wired workflow) should be resolved before merge; the rest are non-blocking. Several concerns cluster around create_release_prs.py, which is currently unused — decide whether to wire it in or defer it from this PR.

[rchiodo]

Most candidate findings target files not present in this PR (upstream-release-sync.yml, scripts/downstream/) and were dropped as not grounded in the actual diff. The real, in-diff problems concentrate in the new downstream-push. agentic workflow: it runs a 20-minute bypassPermissions Claude job on every push to main, yet is wired read-only and cannot perform the cross-repo writes its prompt asks for, and that prompt is itself truncated. Please reconcile that agentic path with the new deterministic downstream-release-dispatch.yml before merging.

[rchiodo]

The dispatch fan-out has a critical heredoc bug that prevents it from running at all, and the loop isn't resilient to per-repo failures. Switching to jq -n --arg ... | gh api --input - and isolating per-repo errors would resolve the main concerns. The consumer template also ships a couple of correctness gaps worth tightening. Note: candidate comments referencing downstream-push.* and upstream-release-sync.yml were dropped because those files are not part of this PR's diff.

[Copilot]

Pull request overview

This PR introduces a release-triggered GitHub Actions workflow that fans out a repository_dispatch event (shared-package-release) to a set of downstream consumer repositories, and adds documentation to help those consumer repos implement a compatible receiver workflow.

Changes:

• Added a release.published workflow that dispatches a shared-package-release event to each configured consumer repository.
• Added a consumer-repository workflow template document describing a starter receiver workflow and the payload contract.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
.github/workflows/downstream-release-dispatch.yml	New release-published workflow that dispatches shared-package-release events to downstream consumer repos.
docs/consumer-repo-dispatch-template.md	New documentation providing a receiver workflow template and listing expected dispatch payload fields.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rchiodo]

Main theme: the dispatch fan-out needs hardening before merge. The JSON payload should be built with jq -n --arg ... rather than an indented heredoc (fixes both the unterminated-heredoc bug and raw JSON-escaping of release values), and per-repo failures should be isolated so one bad consumer doesn't abort the whole loop. Note: candidate comments referencing downstream-push.* and upstream-release-sync.yml were dropped because those files are not part of this PR's diff.

[edvilme]

Addressed the latest review feedback in this PR.

What was fixed:

• Reworked dispatch payload creation to use jq -n --arg ... and gh api --input -, removing the heredoc formatting risk.
• Added per-repo failure isolation in the dispatch loop:
  • each repo dispatch now continues independently on failure
  • failures are collected and reported at the end
  • job exits non-zero if any repository dispatch failed
• Tightened the consumer template correctness:
  • branch is now created from origin/main explicitly
  • replaced local-only pip install example with a tracked-file update example
  • added explicit notes that each consumer repo must adapt file paths/update commands to its real layout

Files changed:

• .github/workflows/downstream-release-dispatch.yml
• docs/consumer-repo-dispatch-template.md

[rchiodo]

Most of the first-pass findings reference an earlier version of the workflow (raw heredoc + unescaped JSON interpolation + no failure isolation) that the current diff already fixes by using jq -n --arg and a per-repo continue/failures loop, so those were dropped as stale. Remaining notes are non-blocking: a real cross-repo token concern and a couple of determinism gaps in the starter template.

[rchiodo]

Approved via Review Center.

[rchiodo]

Overall this is a reasonable release-dispatch fan-out. The dispatch workflow already includes a token preflight and uses cancel-in-progress: false, so most of the workflow-side concerns are already addressed. The remaining feedback is about hardening the canonical consumer template that five repos will copy verbatim.

[rchiodo]

Approved via Review Center.

[rchiodo]

Workflow fan-out looks solid. The blocking feedback is all in the consumer template (docs/consumer-repo-dispatch-template.md): because it's the pattern five repos copy verbatim, the npm/pip steps should pin to the dispatched release_tag (not @latest / bare name) and the commit step needs an existing-branch/PR guard for re-published releases.

[rchiodo]

Main theme: the starter template's update steps don't honor the deterministic release_tag the dispatcher ships. The pip step actually un-pins the dependency, and the npm step installs @latest while the branch/PR text claims the tagged version. Pinning both steps to release_tag (and reconciling the contradicting 'intentionally target latest' note) would make the documented contract internally consistent.

[rchiodo]

Several earlier-iteration concerns (npm installing @latest, the pip step stripping the pin to a bare name, and a 'target latest' notes bullet) appear already resolved in the current diff — npm/pip now pin to the normalized release_version. Remaining notes are optional hardening for the starter template.

[rchiodo]

Approved via Review Center.