Skip to content

Commit 4e2b550

Browse files
docs: condense intro and remove duplicate cross-repo notes in central-repo-ops (#21003)
1 parent 1333b4a commit 4e2b550

1 file changed

Lines changed: 1 addition & 23 deletions

File tree

docs/src/content/docs/patterns/central-repo-ops.mdx

Lines changed: 1 addition & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -8,23 +8,7 @@ description: Operate and roll out changes across many repositories from a single
88
99
CentralRepoOps is a [MultiRepoOps](/gh-aw/patterns/multi-repo-ops/) deployment variant where a single private repository acts as a control plane for large-scale operations across many repositories.
1010

11-
Use this pattern when you need to coordinate rollouts, policy updates, and tracking across tens or hundreds of repositories from a private central location, using cross-repository safe outputs and secure authentication to deliver consistency, control, and auditability.
12-
13-
Below are the key benefits of this pattern for enterprise use cases:
14-
15-
- **Consistency at scale** - Same rollout logic and policy gates across all repositories
16-
- **Risk reduction** - Controlled fan-out (`max`), phased prioritization, and explicit rationale
17-
- **Auditability** - One orchestrator run provides a full decision trail of selection and outcomes
18-
- **Operational agility** - Update workflows in one central repository without pushing `main` changes across dozens or hundreds of repositories
19-
- **Security posture** - Prioritize exposed or vulnerable repositories first
20-
21-
22-
## When to Use CentralRepoOps
23-
24-
- **Organization-wide rollouts** - Apply one change pattern across dozens or hundreds of repositories.
25-
- **Central governance** - Keep prioritization, approvals, and reporting in one control repository.
26-
- **Phased adoption** - Roll out by waves (pilot first, then broader groups).
27-
- **Security operations** - Prioritize repositories with alerts or higher exposure.
11+
Use this pattern for organization-wide rollouts, phased adoption (pilot waves first), central governance, and security-aware prioritization across tens or hundreds of repositories. Each orchestrator run delivers consistent policy gates, controlled fan-out (`max`), and a complete decision trail — without pushing `main` changes to individual target repositories.
2812

2913
## Example: Dependabot Rollout (Orchestrator + Worker)
3014

@@ -373,12 +357,6 @@ jobs:
373357
GH_AW_READ_ORG_TOKEN: ${{ secrets.GH_AW_READ_ORG_TOKEN }}
374358
```
375359

376-
> [!NOTE]
377-
> Cross-repository `workflow_call` requires the caller and the callee to be in the **same organization** or the callee repository must be public. The called workflow's `on.workflow_call` section must be present (added in the orchestrator step above).
378-
379-
> [!TIP]
380-
> Cross-repository calls support `secrets: inherit` — the caller's secrets (including `COPILOT_GITHUB_TOKEN`) are passed through automatically. Premium Copilot requests bill to the caller's token, not the platform's.
381-
382360
### Trade-offs: Schedule Only vs Trigger File
383361

384362
| | Schedule only | Trigger file + `workflow_call` |

0 commit comments

Comments
 (0)