<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=591824) </details> <!--IssueSummary end--> ## Problem Applying governance policies (push rules, branch protections, compliance frameworks) to hundreds of projects requires iterating per-project via individual API calls. There is no atomic group-wide operation for project settings enforcement, no built-in rate limiting for bulk operations, and no concurrency management. Every enterprise managing compliance at scale builds the same boilerplate: API iteration loops, retry logic, rate limit handling, error management, and progress reporting. Note: GitLab supports bulk *compliance framework assignment* via UI (since 17.11), but this does not extend to push rules, branch protections, or other project settings. The gap is enforcement of settings, not labeling. ## Agentic Context The DAP Software Factory (&21067, Q2 roadmap) creates projects at scale as part of spec-driven SDLC workflows. Every agent-created project needs governance applied as an onboarding step. Bulk policy application is the mechanism that ensures agent-scaffolded projects are governed from creation. Without it, there is a window between project creation and manual governance configuration where the project is unprotected. See also: &21086 (DAP Project Onboarding Page, FY27-Q2) which creates AGENTS.md and runs context init for new projects. Governance onboarding should be part of the same workflow. ## Prior Art This was previously proposed in #432186 ("Setting rules across projects", under Epic &12248 "Applying settings to multiple projects"), which was closed in August 2025 without implementation. New field evidence from regulated enterprise deployments warrants revisiting: the demand is concrete, the workarounds are fragile, and the compliance frameworks that customers depend on (#588389, Epic &14897) need settings enforcement to be meaningful. ## Field Evidence A Professional Services tool deployed at a regulated enterprise customer processes hundreds of projects through a 5-stage streaming pipeline with adaptive concurrency (auto-reduces on HTTP 429, auto-increases on success). It applies policies to all matching projects in a single command with constant-memory processing. ## Proposal 1. Provide a group-level API endpoint that applies push rules, branch protections, and/or compliance frameworks settings to all projects in the group hierarchy in a single call 2. Support filtering: by namespace glob, by topic, by compliance framework label, by archived status 3. Return a structured report of changes applied per project (success/failure/skipped) 4. Support dry-run mode (preview changes without applying) 5. Handle rate limiting and concurrency internally ## Related Issues - #432186 -- "Setting rules across projects" (closed predecessor, Epic &12248) - #545421 -- Organization-level settings enforcement (UX research) - #292948, #221261 -- recursive push rule application requests ## DAP & AI Governance Cross-References - &14897 -- Custom compliance frameworks improvements (proposed parent epic) - &21067 -- DAP Software Factory (agent-created projects need governance onboarding) - &21086 -- DAP Project Onboarding Page (governance should be part of project init) - #588234 -- Custom Agent Lifecycle Management (governance as lifecycle gate) ## Part of Governance-as-Code Series This is one of 9 related issues: #591821, #591822, #591823, #591824, #591825, #591826, #591827, #591828, #591829