GitLab Migration - give informative response when application setting is disabled
Release notes
For GitLab group and project migration to work both GitLab instances have to have that feature enabled in application settings by an instance administrator. Until now, if you tried to initiate import when the feature was disabled, you received a 404 error message as a response. We replaced it with an informative message and indication how to enable the feature.
Problem
Follow up from #383268 (comment 1233803759).
Both GitLab instances have to have migration enabled in application settings by an instance administrator.
Whenever GitLab Migration is disabled and a user makes a network request to initiate a new migration - a 404 response is returned. This response should include a message about the importer being disabled to better indicate why the 404 response is returned back to the user.
Proposed solution
-
API: If the setting is off on target OR destination instance and user tries to migrate via API they should get an informative feedback:
"Group import disabled on source or destination instance. Ask an administrator to enable it on both instances and try again. https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer"
-
UI (disabled on source): There should be error message shown to the user when they click on "Connect instance" and that instance (source) doesn't have the application setting turned on. Error message:
"Group import disabled on source instance. Ask an administrator to enable it and try again.
-
UI (disabled on destination): When admin setting is disabled on target instance, UI for migrating by direct transfer is greyed out. There should be informative message:
"Group import disabled. Ask an administrator to enable it and try again."
Technical implementation
@rodrigo.tomonari comment: I believe we don't have an API to check if an application setting is enabled/disabled.
So, to determine if GitLab Migration is disabled, we can make a request to GET /groups/:id/export_relations/status
or GET /projects/:id/export_relations/status
if the response is 200 the feature is enabled. And if the response is 404, it's disabled, and we should return an error to the user.
The endpoints return a 404 if the source GitLab instance is old and the endpoints aren't implemented. However, the backend already checks if the source instance version is compatible. So if we add the settings validation after the version validation, a 404 will mean the setting is disabled.
-
In case of 404 because the GL instance version is too old, show error message: "Unsupported GitLab version. Minimum supported version is GitLab 14.0."
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.