Create a Central Repo Ops Workflow for Action Distribution

[strawgate]

Let's create a model like this where we can distribute actions and action updates to downstream users of our actions https://github.github.com/gh-aw/patterns/centralrepoops/

[github-actions]

This issue appears to be a duplicate of #245 — Downstream Updates Needed workflow.

Both request a central workflow to identify downstream repositories using these actions and manage/drive required workflow updates for those downstream users.

Linking to the existing issue for tracking. If this is actually a different problem, please add more details to distinguish it.

---

What is this? | From workflow: Duplicate Issue Detector

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #248

[strawgate]

/ai 245 is about notification, the github link i shared is about automation, please plan out the automation for opening PRs in the remote repos to update workflows as needed

[github-actions]

TL;DR: I recommend implementing this as an internal orchestrator + worker pair that uses data/downstream-users.json as the target inventory and opens cross-repo PRs for pinned workflow SHA updates, rather than exposing another consumer-facing workflow.

Recommendation

Build a CentralRepoOps-style distribution system in this repo with two internal workflows:

1. Orchestrator: selects target downstream repos/workflows from data/downstream-users.json, applies rollout policy (max, waves, exclusions), and dispatches worker runs.
2. Worker: for each target repo, updates pinned elastic/ai-github-actions/.github/workflows/gh-aw-*.lock.yml@(sha) refs to latest release SHA and opens one PR.

This aligns with your linked pattern and reuses existing assets already in this repo.

Findings

• Existing building blocks already cover discovery + release intelligence, but not cross-repo distribution:
  • .github/workflows/gh-aw-downstream-users.md:83 writes data/downstream-users.json (inventory).
  • .github/workflows/gh-aw-downstream-users.md:100-110 defines downstream usage discovery/normalization.
  • .github/workflows/gh-aw-downstream-users.md:65-67 currently allows only noop safe output (no cross-repo action yet).
• Release-update consumer trigger exists:
  • .github/workflows/trigger-release-update.yml:14 calls gh-aw-release-update.lock.yml.
  • .github/workflows/gh-aw-release-update.lock.yml:24 indicates the lock workflow exists.
• There is active drift work relevant to rollout reliability:
  • Issue #235 + PR #247 track missing gh-aw-release-update.md source and internal-only documentation cleanup.
• Release propagation model already exists via v0 tag:
  • .github/workflows/release.yml:3-5 and :79-92 show semver release + force-update of major tag.
  • docs/workflows/gh-agent-workflows.md:126 states downstream updates propagate when v0 moves.
• Historical intent is consistent:
  • Issue #113 requested downstream update PR workflow.
  • Issue #119 established internal downstream-user tracking.

Verification

I ran workflow compilation locally to verify current behavior and identify current gaps:

$ make compile
...
⚠ Compiled 31 workflow(s): 0 error(s), 10 warning(s)

Notably, compile output includes gh-aw-downstream-users.md but does not compile a gh-aw-release-update.md source (consistent with #235/#247 drift discussion).

I also verified missing release-update source file in the current branch:

$ ls .github/workflows/gh-aw-release-update.md
ls: cannot access '.github/workflows/gh-aw-release-update.md': No such file or directory

Detailed Action Plan

1. Stabilize release-update source of truth first

   • Merge/finalize #247 so .github/workflows/gh-aw-release-update.md exists in canonical location.
   • Re-run make compile and ensure release-update participates in normal compile flow.

2. Add internal orchestrator workflow (new .github/workflows/gh-aw-central-repo-ops.md)

   • workflow_dispatch + optional schedule.
   • Inputs: max-repos, repo-allowlist, repo-denylist, dry-run, wave.
   • Read data/downstream-users.json; select candidates with deterministic ordering.
   • Safe output: dispatch-workflow (allowlist only central worker workflow).

3. Add internal worker workflow (new .github/workflows/gh-aw-central-repo-ops-worker.md)

   • workflow_dispatch with target_repo + selected workflow refs.
   • Fetch latest ai-github-actions release + resolve tag→SHA (reuse release-update approach).
   • Update pinned refs in target repo workflows.
   • Safe outputs: create-pull-request targeting target_repo (single PR cap per repo/run).

4. Use existing inventory and docs surfaces

   • Continue using data/downstream-users.json as authoritative candidate list.
   • Update DEVELOPING.md + gh-agent-workflows/DEVELOPING.md to mark these as internal-only workflows (same pattern as gh-aw-upgrade-check / downstream-users internal model).

5. Guardrails and rollout controls

   • Add explicit max fanout + dry-run no-op summary mode.
   • Add per-repo idempotency check (skip when already at latest SHA).
   • Add run summary with selected/skipped/updated counts and rationale.

6. Validation

   • make compile
   • make lint
   • Dry-run against a small allowlist (2-3 repos), then one real wave.

Related Items

Type	Link	Relevance
Issue	#248	Current request (CentralRepoOps-style distribution)
Issue	#113	Original request for release update PR automation
Issue	#119	Internal downstream user tracking requirement
Issue	#235	Current drift that affects release-update source reliability
PR	#126	Added downstream users tracking workflow
PR	#247	Active fix for release-update/downstream-users drift/docs
File	.github/workflows/gh-aw-downstream-users.md	Existing downstream inventory workflow
File	data/downstream-users.json	Current downstream target inventory
File	.github/workflows/trigger-release-update.yml	Existing release-update trigger
File	.github/workflows/release.yml	Release + v0 movement semantics
Web	https://github.github.com/gh-aw/patterns/centralrepoops/	Requested architecture pattern

---

What is this? | From workflow: Issue Triage Agent

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #248

[github-actions]

Key takeaway: implement this as a central orchestrator workflow in this repo plus a reusable updater workflow committed into each downstream repo, then have the orchestrator fan out workflow_dispatch calls and let each downstream repo open its own PR.

Grounding in current repo:

• data/downstream-users.json already provides target inventory (data/downstream-users.json:1).
• Downstream discovery is already automated, but only with noop safe output (.github/workflows/gh-aw-downstream-users.md:65-67, :83).
• Current downstream health path creates issues, not update PRs (.github/workflows/gh-aw-downstream-health.md:65-71).
• Release update trigger exists (.github/workflows/trigger-release-update.yml:14), and the lock workflow imports a missing source (.github/workflows/gh-aw-release-update.lock.yml:665, source file absent in repo).

Automation plan for remote PR creation

1. Stabilize source workflow drift first

   • Restore .github/workflows/gh-aw-release-update.md so compile/source-of-truth is consistent before adding distribution logic.

2. Add central orchestrator (this repo, internal-only)

   • New workflow (scheduled + manual) reads data/downstream-users.json.
   • Filters targets (allowlist, denylist, max_repos, dry_run, wave).
   • Dispatches workflow_dispatch to downstream repos via GitHub API using a repo-scoped app/token.

3. Add downstream reusable updater workflow (in downstream repos)

   • Receives target_sha/target_tag + optional workflow allowlist.
   • Updates pinned uses: elastic/ai-github-actions/...@(sha) refs.
   • If changes exist, opens one PR in that downstream repo with summary of touched files.

4. Rollout model

   • Wave 0: 1-2 repos (e.g., elastic/infra-party, elastic/integrations).
   • Wave 1+: expand automatically when success rate and latency thresholds pass.

5. Safety and idempotency

   • Skip repos already on target SHA.
   • Per-repo lock/concurrency to avoid duplicate PRs.
   • Retry transient API failures; hard-fail on permission errors with clear repo list.

6. Observability

   • Central run summary: selected/skipped/succeeded/failed repos + PR links.
   • Optional follow-up issue only for failures needing manual remediation.

If you want, I can turn this into an execution checklist by opening 3 implementation issues (orchestrator, downstream updater, rollout/observability) with acceptance criteria.

---

What is this? | From workflow: Issue Assistant

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #248