The Support Team can offer to import a few projects as a best effort courtesy, but anything complex with a hundreds of users or projects is out of scope. These users should be referred to Professional Services.
The import method is a GitLab project export file.
The requestor should be an existing customer or a prospect.
The import was attempted and failed one or more times.
The target location is a group (not a personal namespace, can be transferred if necessary).
json.path and filter: json.severity: (not INFO) or
json.controller: Projects::ImportsController with error status
In Sentry, search/look for: Projects::ImportService::Error ; make sure to remove is:unresolved filter
If there is an error, search for an existing issue, for example award emoji on snippets. Similar errors where the metadata is throwing an error and no issue exists, consider creating one from Sentry.
If no error is found and the import is partial, most likely it is a timeout issue.
Case 1: Large imports
Due to CE issue #52956, users with large projects (~1GB+) will often hit the timeout. Imports stop when it hits an error or a timeout, but will always create the barebones resulting in partial imports.
Options to reduce project size:
cutting down the repo size (if that's what's large) via a cleanup first using docs and ensuring/running git gc and housekeeping
cutting down what's exported by editing the import_export.yml file (in self-managed instance), see this and 2-3 following comments: https://gitlab.com/gitlab-org/gitlab-ce/issues/52956#note_112117847
Note, these are noted in the macro GitLab.com::Import::Verify import criteria.
When in doubt, file an issue in dotcom-escalations and ask for a manager's input. If a manager approves, proceed with the import.
Before offering to do the import, verify the following:
User is a group owner.
User has rights to create new projects in the space.
If not verified, let the user know we might be able to offer an import, but a group owner needs to contact us or they need to adjust their settings (depending on which of the above is not verified) using GitLab.com::Import::Verify import criteria macro.
Offer import and gather information
Offer for the GitLab team to do an import on their behalf as a courtesy using the GitLab.com::Import::Offer import macro.
Ask the user to (in macro):
confirm the group where the project should be imported.
confirm no project currently exists in the namespace with the project's name.
provide a copy of their project's export. Recommended sites: send.firefox.com (up to 1GB, expires after 24 hours), wetransfer.com (up to 2 GB).
Depending on the case:
Correctly mapped users: that all active users have accounts on GitLab.com with matching company email address as their primary email account. All email addresses in the project export should have the company domain.
No user mapping: provide the username for items to be attributed to.
Provide date/time with timezone when they will send us the export at least 1 business day in advance.
If scheduling ahead of time, create the infra issue with all available information (see below for details).
After receiving export
When receiving the project export: download, and ensure it unpacks. If not, ask the user for another copy.
For correctly mapped users only:
In a command line window, navigate to the folder where the project export resides.
Use the export file user checker to verify that all the email addresses exist on GitLab.com. If not, respond to the customer with the list of email addresses not in GitLab.com.
Reminder: The API and importer only checks primary email address, so users will match only on the one email address. Users can temporarily switch primary/secondary and switch them back if necessary.
If the customer responds that emails not in GitLab.com are employees no longer with the company, we can proceed. Items will be mapped to the admin account then the ghost user once the account is deleted.
Also check that domain of email addresses belong to the company in the resulting list.
Create a folder to unpack into: mkdir project_export
Unpack the project into a folder: tar -zxvf filename.tar.gz -C project_export
Navigate into the resulting folder using: cd project_export
Rename the project.json file: mv project.json project_old.json
If scheduling ahead of time, add date/time with timezone and post in Slack #production (no ping). Add export link later. Example message: "Hi team, got an import request scheduled for 2019-00-00 at 00:00 UTC. Appreciate if you could assign this to whomever is on-call at the time. LINK"
If not scheduling, use today's date and "at earliest convenience". Ping the on-call (check chatops) with the request. Example: "Hi @user, got an import request. Could you kick this off when you have a few minutes? LINK"
For correctly mapped users only: Fill out an access request template on the access-requests tracker for admin level access to perform the import (see subsection for details).
Add infra issue link as internal note to the ZD ticket.
Delete any local copies of the export.
Imports may take a long time, so pass it on to the next region if necessary.
A message will be sent to #announcements channel on Slack when done. Close infra issue.
Ensure the export file is deleted (if applicable).
Let the user know the import is done and they should double check its completeness.
After customer confirms everything looks okay, if applicable, submit account removal request to delete admin account.
Access request information
Use the Free form request information section (replace group with org or group name):
Admin user access for customer import for infra's use with username: `group-import`
Import request: INFRA-ISSUE-LINK