CentralRepoOps examples only showed schedule: as the orchestrator trigger, leaving no documented path to react to GitHub events (issues, pushes, labels) without recompiling the agentic workflow.

Changes

• New section: "Richer Triggers with a Trigger File" in central-repo-ops.mdx covering:
  • Adding workflow_call to the orchestrator frontmatter (alongside schedule:) so it can be called externally
  • A stable, hand-authored trigger .yml that references the compiled .lock.yml and uses secrets: inherit — this file survives recompiles unchanged
  • A cross-repo workflow_call example showing how a trigger file in a target repository can call back into the orchestrator in the central control repo
  • Trade-off table: schedule-only vs trigger file across setup cost, flexibility, recompile coupling, and event context forwarding

Pattern in brief

Same-repo trigger file (lives alongside the orchestrator in the central repo):

on:
  issues:
    types: [labeled]
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  trigger:
    uses: ./.github/workflows/dependabot-rollout-orchestrator.lock.yml
    with:
      reason: ${{ github.event_name }}
    secrets: inherit

Cross-repo trigger file (lives in a target repo, calls back into the central repo):

jobs:
  trigger:
    uses: my-org/central-ops/.github/workflows/dependabot-rollout-orchestrator.lock.yml@main
    with:
      reason: "${{ github.event_name }} in ${{ github.repository }}"
    secrets:
      GH_AW_READ_ORG_TOKEN: ${{ secrets.GH_AW_READ_ORG_TOKEN }}

The key insight: the trigger file is plain YAML (no compilation), so trigger conditions change independently of the agent logic. Cross-repo calls require secrets to be listed explicitly (secrets: inherit is not supported).

Custom agent used: technical-doc-writer
AI technical documentation writer for GitHub Actions library using GitHub Docs voice

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.