<!--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=591821) </details> <!--IssueSummary end--> ## Problem Group-level push rules only apply to projects created **after** the rule is set. Existing projects are not updated and must be configured individually. Additionally, push rules can be deleted or overridden at the project level with no prevention mechanism. This is inconsistent with branch protections, which **are** enforced from group level and cannot be overridden at project level. This gap breaks **continuous compliance**: an administrator cannot declare a compliance posture and trust it will be maintained across all projects. ## Agentic Context As GitLab's Duo Agent Platform (DAP) scales, agents create projects programmatically via DAP flows and the Software Development flow. Every auto-scaffolded project inherits no push rules from the parent group. At agent scale (dozens of projects created per day), this means every new project is ungoverned by default. Push rule enforcement at group level with automatic inheritance is a prerequisite for governed agentic SDLC operations. ## Field Evidence A Professional Services tool deployed at a regulated enterprise customer enforces desired push rule state across hundreds of projects declaratively. If someone overrides a push rule at project level, the next enforcement run restores it. This capability does not exist natively in GitLab, forcing enterprises to build or buy external tooling. ## Current Workaround External scripting or PS-built tooling that iterates over all projects via API and applies push rules individually with retry logic and rate limit handling. ## Proposal 1. Group-level push rules should propagate retroactively to all existing projects in the group hierarchy 2. Add a "lock" mechanism (similar to cascading settings `enforce` flag) that prevents project-level override of group push rules 3. When a group push rule is locked, project-level push rule UI should show the inherited value as read-only ## Prerequisites The push rules table migration (#499156, milestone 19.1) is a likely prerequisite for this work. The cascading settings framework (#483143) also needs to propagate changes to children on update. ## Related Issues - #553531 -- community bug report confirming group push rules not enforced on projects - #499156 -- push rules table migration (milestone 19.1, active) - #483143 -- cascading settings should update children on update (prereq) - #482510 -- split read/admin push rules permissions - #325680 -- same pattern for MR approval rules at group level - #34370, #292948, #221261, #546652 -- prior requests for retroactive push rule application ## DAP & AI Governance Cross-References - &14897 -- Custom compliance frameworks improvements (proposed parent epic) - &20418 -- AI Agent Policy Enforcement & Guardrails (shared enforcement theme) - &18954 -- Comprehensive AI Audit Event System (push rule changes generate audit events) - #585927 -- DAP Governance: Enforceable security policies (overlapping scope) - #588389 -- Use Compliance Frameworks to determine DAP availability (sibling in &14897) ## Part of Governance-as-Code Series This is one of 9 related issues proposing native governance enforcement at scale: #591821, #591822, #591823, #591824, #591825, #591826, #591827, #591828, #591829