Repository navigation
Question: Can gh-aw support central label triggers across repositories? #33619
Description
Hi gh-aw team, quick question about CentralRepoOps trigger semantics.
For a central workflow hosted in one repository, is there any feasible path for gh-aw to provide a core trigger primitive where a label added to a pull request in another allowed repository can activate the central workflow directly?
Example desired shape:
on:
central_pull_request_labeled:
label: ns-pattern-review
allowed-repos:
- my-org/*Intended behavior:
- A maintainer adds
ns-pattern-reviewto a PR inmy-org/example. - A central workflow in
my-org/central-agentsactivates. - The central workflow receives typed inputs like:
target_repopr_numberhead_shabase_shatrigger_labeldelivery_idactor
We understand GitHub Actions events are repository-local, so this may be a GitHub platform limitation rather than something gh-aw can implement as a native trigger.
If native central label triggers are not possible, would the recommended gh-aw direction be a documented bridge pattern, such as:
- GitHub App webhook receiving
pull_request.labeled - webhook validates repo/label/PR state
- webhook dispatches the central workflow with typed inputs
Mostly trying to confirm whether this belongs as a gh-aw core trigger primitive, a documented CentralRepoOps bridge pattern, or entirely outside gh-aw.
Thanks!
Activity
pelikhan commentedon May 26, 2026
Add a new trigger label_dispatch that forces the compiler to generate an additional action YAML file that triggers on the label. That trigger iml file is meant to live on the remote repo (.remote.yml) This file is meant to be deployed in another repo, triggers on label, validates and repo dispatches. The current action would then receive a repository dispatch with the usual context.
pelikhan commentedon Oct 7, 2026
Status (2026-10-07; Maintainer direction): On 2026-05-26, a maintainer proposed a
label_dispatchtrigger that generates a.remote.ymlworkflow for the other repository to validate the label and dispatch to the central workflow. The next step is to define and review that generated workflow and its dispatch inputs.pelikhan commentedon Oct 16, 2026
Current-state refresher — 2026-10-16
Verdict: Still relevant for cross-repository activation; existing label routing is not the requested bridge. Reviewed current
mainat0d15bd1649f6and the maintainer's.remote.ymlproposal.Merged #31917 provides
label_command.strategy: decentralized, generating label routes inagentic_commands.yml. The current route collector includes labeled events, and the runtime forwardsaw_context.However, the actual dispatch implementation explicitly targets
context.repo.owner/context.repo.repo. That centralizes routing within the event's repository; it does not make a label in repository A directly activate a workflow in central repository B.Remaining: specify and ship/document the authenticated cross-repository bridge (generated remote listener or GitHub App), repository/label/actor validation, and target/PR/SHA/delivery payload contract. Native Actions events remain repository-local. No cross-repository event delivery was exercised; existing routing is reusable plumbing, not completion of this feature.
pelikhan commentedon Oct 22, 2026
Relevance check — 2026-10-22: keep open; cross-repository label activation is not delivered. Checked live remote
mainatffdd9c9efe6a.The directly relevant #34836, which proposed
label_dispatchplus a generated.remote.ymlbridge and the requested typed payload, is closed and unmerged. Merged #31917 only supplies decentralized label routing: the current route collector handles label events, but the dispatcher still targetscontext.repo.owner/context.repo.repo. That does not move a label event from source repository A to central repository B.Next concrete step: specify and ship/document the maintainer-proposed remote listener or an authenticated GitHub App bridge. Define source/destination repository allowlists, label/actor/PR-state checks, dispatch credentials and receiving authorization, delivery deduplication, and the
target_repo,pr_number,head_sha,base_sha,trigger_label,delivery_id,actorcontract. Existingrepository_dispatchis usable receiving plumbing, not an already-shipped bridge. Static/API review only; no dispatch performed.pelikhan commentedon Oct 22, 2026
@bbonafed cross repo will be supported by the webhook gateway in central agentic ops.