Summary
Introduce configuration for monorepos to either group changes by directory (one PR per service) or force a single consolidated PR, giving platform teams control over rollout granularity.
Why
Monorepos frequently host many independent services. Opening one massive PR can overwhelm reviewers, while splitting by service helps staged rollouts. Conversely, smaller repos may prefer a single PR even when multiple tracks are detected.
What needs to happen
- Add inputs such as
group_by: directory and single_pr: true (mutually exclusive) to control branch/PR creation.
- Adjust change matrix and branch naming to reflect grouping decisions.
- Ensure PR titles/bodies reflect the scope (service name or directory).
- Provide tests for directory grouping, single PR fallback, and default behavior.
- Document the new options with examples.
References
- Roadmap capabilities item: "Monorepo quality of life".
Acceptance criteria
- Users can opt into directory grouping and receive separate branches/PRs per top-level path.
- Default behavior (single PR per run) remains unchanged unless explicitly configured.
- Documentation and examples show both workflows.
Summary
Introduce configuration for monorepos to either group changes by directory (one PR per service) or force a single consolidated PR, giving platform teams control over rollout granularity.
Why
Monorepos frequently host many independent services. Opening one massive PR can overwhelm reviewers, while splitting by service helps staged rollouts. Conversely, smaller repos may prefer a single PR even when multiple tracks are detected.
What needs to happen
group_by: directoryandsingle_pr: true(mutually exclusive) to control branch/PR creation.References
Acceptance criteria