Skip to content

Handle cases when submodule SHA in VMR does not match repo's #6444

Description

@premun

We will allow changes to submodules in the VMR. Those will be done by the darc vmr reset-submodule

In forward flows, right now, we look at the changes to the submodules in the original repo. Then we create patches for that diff and apply them on the VMR. Up till now, we did not expect problems there, because the VMR submodules never changed in the VMR only. Now that this is changing, we must be able to support such case.

Technically, this is might be a conflict case - both the repo and the VMR had a change to their submodules - so we won't be able to decide which one should apply.

  • In case the submodule in the repo got rewound to the same SHA that the VMR, we can just no-op as no change is required. Currently, this is also not supported but should be.
  • In case we have different SHAs, we should trigger the conflict flow from the service. In darc, we'd just ignore the submodule change but error out and tell the user that this is the situation. In most cases, this means the VMR had a submodule change the repo does not know about and needs to backflow. Or it's a real conflict. Or the user can resolve it by using darc vmr reset-submodule (maybe the error can mention that too as a remediation and then the two various SHAs that are conflicting).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions