Group push rules do not inherit all settings from instance-level global push rules
Summary
Top-level groups do not properly inherit all settings from instance-level global push rules. While some settings are inherited correctly, others show as not inherited even though they are enabled at the instance level.
Steps to reproduce
- Navigate to Admin Area > Settings > Repository > Push Rules
- Enable all push rule options at the instance level
- Navigate to a top-level group's Settings > Repository > Push Rules
- Observe which settings are inherited
Current behavior
Group push rules are not automatically created, and the UI shows a representation of a missing push rule. The following inheritance behavior is observed:
Inherited correctly:
- Reject unverified users
- Reject unsigned commits
- Reject commits that aren't DCO certified
NOT inherited (but should be):
- Reject inconsistent user name
- Do not allow users to remove Git tags with git push
- Check whether the commit author is a GitLab user
- Prevent pushing secret files
Screenshots
| Instance | Group | Project |
|---|---|---|
|
|
|
Expected behavior
All instance-level global push rule settings should be inherited by top-level groups and displayed correctly in the group's push rules settings.
Workaround
Creating a project within the group will automatically create a push rule from the global push rule and display correct settings for the project.
Additional context
This appears to be a UI/data representation issue where group push rules are not automatically created to reflect instance-level settings, leading to inconsistent inheritance display.
Related code
It appears the issue is that Groups::PushRulesController builds an empty push rule object for the group.
A better option would be to use predefined_push_rule or automatically create a group push rule like it’s done for projects.