BulkImports: Validate Gitlab Source version to avoid failing the import after it started.
Context
The Group Migration tool is mainly based on the GitLab GraphQL API. Unfortunately, this API does not provide all the information required to make a full migration from one instance to another. To fix that, ~"group::import" is evolving the GraphQL API every time a missing information/relation is found.
Problem to Solve
Adding new fields/relations to the GraphQL restricts the migration tool compatibility to only the versions that include the new fields/relations.
Possible Solutions
- Given a group type in graphql was introduced in %11.11 that allows us to migrate group attributes, subgroups, etc.
- A minimum overall version for our tool is v11.11.0 that allows to import just that.
- You recently made a change to epics query to add
includeDescendantGroups: false
attributes, in %13.7. This means that any graphql request we make to instance that is %13.6 or less will result in a syntax error. This puts a version dependency of %13.7 for epics. - Similar thing can be done for other Migration Pipelines. The newer the version the more complete a migration is going to be.
- Each query module (e.g. GetEpicsQuery) would need to have an minimum_version (or a similar name) method that returns a version in which it was introduced/updated
- We can introduce a
before_run
hook that checks source gitlab version and stores it. If version is incompatible - return and do nothing - If a query is modified to use a new syntax that was not available in previous version - it breaks compatibility and we need to update minimum_version to reflect that having minimum_version can play nicely with older version of gitlab if our queries evolve this means some older version can still import to older versions, if their versions match
Checking Gitlab Version
- Rest API: https://gitlab.com/api/v4/version
- GraphQL:
query {
metadata {
version
}
}
Edited by Kassio Borges