[SPIKE] Create migration to de-duplicate ProtectedBranch#name values
For more context open and read this
What currently happens?
- Currently it is possible to create a ProtectedBranch for a project that has the same name as an existing ProtectedBranch.
It is also possible to create a ProtectedBranch with a wildcard name that catches branches already covered by another ProtectedBranch. Or a protected branch for feat/* and one for feat/add/* with conflicting rules i.e. one allows force push and then create another that disallows force push.
What do I expect to happen?
- We can add a simple constraint to prevent duplicating names
We could go about this a few ways
Prevent conflicting wildcards during creation, however, I suspect there are genuine use cases for overlapsAdd logic to rate the ProtectedBranches based on how strong the match is e.g. feat/* would rank lower than feat/add/* for feat/add/branch-rules-loopback-deviceOthers?
I don't think these are great solutions though. We'll either still have edge cases or we'll prevent people from using nested protected branches
Scope
Availability and Testing
Add feature spec to ensure that a user is prevented from creating a protected branch which duplicates the name of an existing protected branch.
Proposed solution
- AR validation for ProtectedBranch#name !115729 (merged)
- BatchedBackgroundMigration to merge/remove duplicates
- DB constraint for protected_branches.name
This issue has been converted to a research spike.
To prevent duplicate protected branch names we have added validations to ProtectedBranch#name
Validate uniqueness of name for protected branc... (!115729 - merged)
The next step is to de-duplicate all the existing records. Jerry has done some initial research into what would happen when multiple protected branches share the same name
spike
The purpose of this- Fully investigate and document (in a new issue) how these rules would be applied.
- Create a development plan on how we would implement a migration to de-duplicate
- Decide if we need to or even can create a database constraint
- Investigate how group-level protected branches affect this plan
Considerations
We now have project-level and group-level protected branches. We need to answer the question, "should group and project level protected branches allow shared names. i.e if a group has a protected branch for main
can the project level protected branches include one for main
.
If we should allow this, how will the rules be applied.
Outcome
- Create a follow-up issue documenting how we will de-duplicate the existing records. This issue should give sufficient detail that the developer can confidently implement without having to do additional research.
- Possibly also create a follow-up issue to create a DB constraint if neccessary
- Possibly also create a follow-up related to group-level protected branches if we find anything that needs to change there too.
As this is a protective piece of functionality it is important that we are very confident that the deduplication is not going to remove protections.
It is going to be important to test our assumptions before we hit production.
It would also be good to do some analysis on how many duplicate rules there are