Skip to content

Improve error message setting disabled on source instance - take II

Carla Drago requested to merge 388093-improve-response-message into master

What does this MR do and why?

This change adds validation to check that importing via direct transfer is enabled on the source instance. If it isn't, a message is returned to the user instructing them to request their admin enable the setting. Other error messages have been added and updated where necessary.

The previous MR-approved change for this ended up revealing a bug, namely that the params passed to the BulkImports::CreateService class are not always an Array, and need to be converted into one.

Otherwise see below for a copy/paste from the original MR.

The changes here are somewhat complicated.

When performing an import via Direct Transfer (aka Gitlab Migration aka Bulk Import) the only method we currently have to validate the Direct Transfer setting is enabled on the source instance is to query one of two endpoints. Either endpoint will return a 404 if the Direct Transfer setting is disabled (as the endpoints are unavailable in this state):

GET /groups/:id/export_relations/status

GET /projects/:id/export_relations/status

The endpoint used depends on the params[:source_type].

Both endpoints also accept an encoded path string instead of an id, which we use in the first instance in these changes as there is no id in the params, only a source_full_path, which is the full path to the source namespace.

However, in some cases the Project or Group entity slug (aka path) has been known to consist of integer characters only, e.g. '12345'. This makes the source_full_path, when inserted into the URL endpoint, appear as an id. This results in the wrong entity being requested/returned.

In these instances we are able to obtain the correct id for the entity through a graphql request.

The changes here implement a solution that uses a simple regex that matches when the source_full_path is only integer characters, and makes the additional graphql request to obtain the correct id before requesting the export_relations/status endpoint.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

To validate the changes to the API message:

  1. git checkout into the 388093-improve-response-message branch
  2. in the UI, under Admin > Settings > General > Visibility and access controls, make sure "Allow migrating GitLab groups and projects by direct transfer" is enabled. [Save] any changes if required.
  1. go to the lib/api/group_export.rb file, line 69 in the code, and monkey patch the endpoint to return not_found!. This is to mimic the behavior of an instance where the setting is disabled:
before
after
  1. Using a personal access token with an api scope, in a terminal make a curl POST request to the gdk.test bulk_imports endpoint to initiate a direct transfer from gdk.test to gdk.test:
curl --location --request POST 'http://gdk.test:3000/api/v4/bulk_imports' \
--header 'Authorization: Bearer [ACCESS TOKEN]' \
--header 'Content-Type: application/json' \
--data-raw '{
    "configuration": {
        "url": "http://gdk.test:3000",
        "access_token": [ACCESS TOKEN]
    },
    "entities": [
        {
            "source_full_path": "source_full_path",
            "source_type": "group_entity",
            "destination_slug": "your-destination",
            "destination_namespace": "your-destination-namespace"
        }
    ]
}'
  1. You should see the response:
{"message":"Group import disabled on source or destination instance. Ask an administrator to enable it on both instances and try again."}

-->

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #388093 (closed)

Edited by Carla Drago

Merge request reports