Resolve conflicts
Conflicts occur when the same data changes in both a feature branch and the main branch. Infrahub's conflict management system is designed to identify these conflicts with precision and provide tools for effective resolution.
Types of conflicts Infrahub detects​
The system automatically detects several types of conflicts:
- Attribute conflicts: The same field of an object has been modified in both branches with different values. For example, the hostname of a device is changed to
router-1in one branch androuter-primaryin another. ForListandJSON-array attributes markedordered: falsein the schema, a difference in element order alone doesn't raise a conflict. - Relationship conflicts: Conflicting changes to object relationships occur when the connections between objects are modified differently in separate branches. For instance, a device might be assigned to datacenter A in one branch and datacenter B in another.
- Schema conflicts: Incompatible schema modifications between branches can cause structural conflicts. This might happen when a field is removed in one branch but modified in another.
- Uniqueness conflicts: Changes that would violate uniqueness constraints upon merge are flagged to prevent data integrity issues. This occurs when both branches create different objects with the same unique identifier.
How to resolve conflicts​
The Proposed Change feature in Infrahub provides comprehensive tools for managing these conflicts with intuitive side-by-side diffs that clearly highlight differences between branches. For step-by-step resolution mechanics during review, see Resolve a proposed-change conflict.
Conflicts can also surface during a rebase. A rebase can't apply a resolution in favor of the main branch, so it stops on a conflict until you address it, and its error lists what each conflict needs:
- A conflict on an attribute blocks the rebase until you resolve it in favor of the branch. Open a proposed change for the branch to choose the branch for the value of an attribute, as described in Resolve a proposed-change conflict. For another property of an attribute, such as its owner or source, use the
ResolveDiffConflictGraphQL mutation with the conflict ID that theDiffTreequery returns. - A conflict on a relationship, such as the datacenter a device is assigned to or a property of that assignment, blocks the rebase until you update the data so that both branches agree.
- A conflict on an attribute that the main branch removed, or between the deletion of an object in one branch and a change to it in the other, also blocks the rebase until you update the data so that both branches agree.
This also applies to a branch in the NEED_UPGRADE_REBASE status after an upgrade, which only a rebase returns to OPEN.
Related​
- Branches — branch lifecycle and concepts
- Rebase a branch — surfaces conflicts early before merge
- Resolve a proposed-change conflict — review-time conflict resolution