The process has changed significantly, removing the previously used infra import process. Please carefully read the criteria and what Support can do.
If a customer is having issues with exporting a project, troubleshoot as normal, including:
Once an issue is created or commented on, you may use the
Support::SaaS::Export::Offer one time macro to offer a one-time export attempt.
If the customer accepts the offer, did the export succeed (they got an email, or there is a "Download export" button) but there an error downloading it? Example: gitlab#330833.
For convenience, two additional macros are available after an export attempt is made:
This workflow is meant to provide guidance on when GitLab Team members might offer to import projects on behalf of customers as a courtesy, and the process for doing the imports. Due to the shifting nature of what issues might be relevant, the specifics of this workflow may change. Overall though, the import process should follow the flow outlined below.
When a request to import a project on behalf of a customer is received, we first need to determine if the request fits the criteria.
If the customer requires that only a couple projects or less be imported and those projects have a reasonable number of users within them, we can do it. If the request is complex or there are many projects that need importing, the requester should be referred to Professional Services instead.
Once you've determined that GitLab Support is able to process the import, proceed with verifying the Baseline Eligibility of all of the projects to be imported or determine that the requestor is approved because they meet the criteria of a Pre-Approved Case.
In addition to the above criteria, we can automatically offer to import a project for a customer if their case falls under the criteria of any of the following sections.
A GitLab.com admin is required to correctly map users in GitLab, per our documentation. Without an admin account, repository commits will have correct user attribution but issues and merge requests will not. We can import a project for a customer if they require this and there are no other issues with their import.
Any request should include a comment on the relevant feature request #223137.
NOTE: All users' emails must be public for contributions to map.
If you're unsure of whether or not we should perform an import for a specific requestor, get input via #support_escalations Slack channel or an internal issue. If a manager approves, proceed with the import.
You can use the
Support::SaaS::Import::Offer Import (Users Mapped) Zendesk macro and then follow the next sections in sequence.
When customers request a specific time period for the imports to be done, they should always do a test import for each project and make note of how long it takes. It can be approximate, but should give everyone a clear idea of whether it's reasonable to be done within the given time period. Remember that additional time is required to do any pre or post import work.
Note that lead time is required for the access request and possibly to find an engineer to do the work, so we recommend at least 2 business days.
admin-accesslabel, you've asked for approval from
@it-ops-teamin the #it_help Slack channel with a link to the request to ensure quick provisioning as soon as you receive a manager's approval.
In the access request, enter the following in the Person Details section, replacing
group-import with the name of the group.
- Admin user access for customer import for Infra's use with username: `group-import-admin` - Set email to: `email@example.com` - Ticket: <TICKET LINK> - Import request: <ISSUE LINK> **Note:** This is part of the [project import process](https://about.gitlab.com/handbook/support/workflows/importing_projects.html) for customers.
Then, enter the following for the Access Request section:
GitLab PRD | Role: `admin` | Please create, confirm, and enable 2FA for this user. Justification: customer import following [project import process](https://about.gitlab.com/handbook/support/workflows/importing_projects.html)
The customer should send you a copy of the project export ahead of their chosen import time (if scheduled) so that there is ample time to do the next section and for the customer to verify the list and correct any errors.
User emails unique to export file:section of the results and ensure that all email addresses listed are on the requestor's company domain, meaning no users have an email address on a generic domain such as Gmail.com.
If issues within the list are found:
Support::SaaS::Import::Verify User List (Problem Found)Zendesk macro, which will ask them to resolve the issues we found and send us a new project export once that's done. Once they have, repeat the 2. Verify User List section.
If no issues within the list are found:
Support::SaaS::Import::Verify User List (Looks Good)Zendesk macro and await their reply. Once they reply and confirm that all email addresses that were found only in the export file are from employees no longer with the company, this section is complete.
NOTE: For these users, items will be mapped to the admin account, then the Ghost User once the admin account is deleted.
For scheduled imports, once we receive a link to the latest file, update the issue with the link to the project and let the assignee know they can begin the import process.
If the import is to be done ASAP and no new project export file is provided, this section is not required.
tar -zxvf filename.tar.gz -C project_export.
After the import has completed successfully, perform the following steps.
Support::SaaS::Import::Complete - Customer to VerifyZendesk macro to let the customer know that the import has completed and that they should double check that everything is in order.
Support::SaaS::Import::Offer Import (Users Mapped)
Support::SaaS::Import::Verify User List (Looks Good)
Support::SaaS::Import::Verify User List (Problem Found)
Support::SaaS::Import::Complete - Customer to Verify
Time And Date can be used to convert timezones to UTC, useful for when imports are scheduled for a future time.