Skip to content

BulkImports: avoid infinity recursion on group migration

What does this MR do?

The current subgroup migration strategy works iteratively, which means that each level of a group tree is imported before moving to the next level.

This becomes a problem when the target group is within the source group, which creates a infinity loop of import.

Example:

Given a group tree like:

  • Group A
    • Group B
    • Group C
      • Group X
      • Group Y

If one decide to import the Group A into Group B, a recursion will happen, making the import stop only when the depth limit is achieved or some other database constraint, like the size of a group path.

  • Group A
    • Group B
      • Group A
        • Group B
          • Group A
            • Group B
              • Group A
                • Group B
                  • ...
                • Group C
                  • Group X
                  • Group Y
            • Group C
              • Group X
              • Group Y
        • Group C
          • Group X
          • Group Y
    • Group C
      • Group X
      • Group Y

To fix that, destination namespaces cannot be a descendant of the source group.

Related to: #300445 (closed)

Update (2021-02-01)

Screenshots (strongly suggested)

image

Screen_Recording_2021-01-28_at_6.20.42_PM

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Kassio Borges

Merge request reports