Branch rule squash settings not applied consistently when both group and project level rules exist
Summary
When branch rules exist at both group and project level, squash settings configured on the project-level rule show as applied only when the project-level rule is listed first in the branch rules list. The behavior is inconsistent and depends on the order of rules in the UI.
Steps to reproduce
- Create a group-level branch rule for a branch (e.g.,
main) - Create a project-level branch rule for the same branch with a squash setting (e.g., "Do not allow")
- View the branch rules list in the project settings
- Observe the squash settings in the GraphQL response or UI.
In this case, the behaviour will be expected. The squash option is applied.
However, we see cases in production where group-level rule is listed first in the list. In these cases, the squash setting doesn't appear as.
Current behavior
The squash settings are only properly applied when the project-level rule appears first in the list. When the group-level rule appears first, the project-level squash settings are not shown or applied correctly.
Expected behavior
Squash settings should be applied consistently regardless of the order in which branch rules appear in the list. The most specific rule (project-level) should take precedence over the less specific rule (group-level), and this should be reflected consistently in both the UI and GraphQL responses.
Environment
Reproduced on gitlab.com
Example project
See this project for a demonstration of the issue: https://gitlab.com/gl-demo-ultimate-khrechyshkina/branch-rules-test-group/branch-group-project/-/settings/repository#branch-rules
Note that main branch shows the correct behavior while production branch shows the incorrect behavior.
Additional context
The squash settings should follow this hierarchy consistently regardless of the order they appear in the UI.