<!--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> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=593114) </details> <!--IssueSummary end--> ## Summary The `project_settings.push_rule_id` column should be removed as part of the push rules table restructuring for Cells 1.0. This column is written to but never read in production code paths, and its FK constraint to `push_rules` blocks the migration to `project_push_rules`. ## Background As part of [Cells 1.0](https://gitlab.com/groups/gitlab-org/-/epics/15534), the `push_rules` table is being split so each entity type has its own dedicated table (`organization_push_rules`, `group_push_rules`, `project_push_rules`). The [implementation plan](https://gitlab.com/gitlab-org/gitlab/-/work_items/588805#implementation-plan) covers reads, writes, FF rollout, FF cleanup, and trigger removal. The `project_settings.push_rule_id` column was introduced in [!28286](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28286) with the intent of having consistent push rule pointers from `ApplicationSettings`, `Group`, and `ProjectSettings` to the `push_rules` table. ## Problem `project_settings.push_rule_id` has a FK constraint (`fk_project_settings_push_rule_id`, `on_delete: :nullify`) pointing to the `push_rules` table. With the new `project_push_rules` table using its own ID sequence, storing a `project_push_rules` ID in this column would violate the FK constraint. In !225833, we chose to skip updating this column entirely when `write_project_push_rules` is enabled (Option 3 from the [MR discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/225833#note_3141066677)), since the column is not read in production. ## Evidence that the column is not read The `belongs_to :push_rule` association exists on `EE::ProjectSetting` (`ee/app/models/ee/project_setting.rb`), but no production code reads through it. All push rule reads go through `project.push_rule` or `ProjectPushRuleFinder`. The column is only **written** in three places: 1. `ee/app/services/push_rules/create_predefined_rule_service.rb` - project creation 2. `ee/app/controllers/ee/projects/settings/repository_controller.rb` - repository settings page load 3. `lib/gitlab/github_import/importer/protected_branch_importer.rb` - GitHub import All references to `project_setting.push_rule_id` being **read** are in spec files only. **Note**: Before cleaning it up, make sure `project_setting.push_rule_id` is actually not read. ## Cleanup steps 1. Remove the `belongs_to :push_rule` association from `EE::ProjectSetting` 2. Remove all writes to `project_setting.push_rule_id` / `project_setting.push_rule` in the three call sites above (some already skipped behind FF) 3. Drop the FK constraint `fk_project_settings_push_rule_id` 4. Remove the `push_rule_id` column from `project_settings` 5. Update specs that assert on `project_setting.push_rule_id` ## Timing This cleanup should happen after: - Phase 4 (FF cleanup) of the [implementation plan](https://gitlab.com/gitlab-org/gitlab/-/work_items/588805#implementation-plan), when the feature flags are removed and all reads/writes go through `project_push_rules` ## References - Parent issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/588805 - Writes MR (Option 3 decision): https://gitlab.com/gitlab-org/gitlab/-/merge_requests/225833 - Original MR that introduced the column: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28286 - Discussion: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/225833#note_3141066677