Improve error message setting disabled on source instance - take II
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 noid
in the params, only asource_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 thesource_full_path
, when inserted into the URL endpoint, appear as anid
. 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 correctid
before requesting theexport_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:
git checkout
into the388093-improve-response-message
branch- 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.
![]()
- go to the
lib/api/group_export.rb
file, line 69 in the code, and monkey patch the endpoint to returnnot_found!
. This is to mimic the behavior of an instance where the setting is disabled:before
![]()
after
![]()
- Using a personal access token with an
api
scope, in a terminal make a curl POST request to thegdk.test
bulk_imports endpoint to initiate a direct transfer fromgdk.test
togdk.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" } ] }'
- 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.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #388093 (closed)