This document details the various workflows that should be followed in order to properly service requests that we receive in the dotcom-internal issue tracker along with which template to use if you need to open an issue in it yourself to document an action taken on a GitLab.com user or group. First, it will go over the general workflow you should follow when faced with a new issue in dotcom-internal and then it will inform you how to perform the specific tasks required to process each type of request.
Plan Change Requests & Trial Extensions
A[Issue Created]-->B[Assign Yourself];
J-->K[Apply Status::Blocked and Inform Submitter];
D-->E[Adjust Namespace via Customers Portal];
E-->F[Did it Work?];
G-->H[Note Issue and Close];
I-->L[Locate Error in Sentry];
click L "https://about.gitlab.com/handbook/support/workflows/500_errors.html#searching-sentry" "Diagnose Errors on GitLab.com"
L-->M[Adjust Namespace Manually];
M-->N[Apply Status::On Hold, Set Due Date, and Inform Submitter];
Sales will often request that we extend the duration of GitLab.com trials on behalf of their prospects. These issues will always have the Trial Extension label applied to them and the following workflow should be followed to service them.
If any fields in the issue description were filled out incorrectly by the submitter apply the Status::Blocked label and mention them in the issue asking them to supply any missing information.
Assign yourself to the issue.
Check over the request and ensure that we've been provided enough information to action the request. To do this check that:
The GitLab.com Link to Namespace: field contains a valid GitLab.com link to the namespace that holds the active trial. This should not be a Salesforce link or email address.
The Extend Until: field contains a future date.
Check to ensure that the namespace is currently on an active Gold trial. This process varies depending on whether you're dealing with a personal or group namespace.
Personal namespaces: Impersonate the user and navigate to their billing page.
Group namespaces: Navigate to Settings -> Billing within the group.
Using the address provided in the Contact Email: field log into the Customers Portal as an administrator, input the email address into the search field, and search.
Navigate to the GitLab Groups section of the entry for the customer.
Adjust the subscription type and expiration date of the correct namespace according to the details of the issue using the Plan and Trial columns.
Set the due date of the issue to the value of what was provided in the Extend Until: field.
Revert the subscription type of the namespace back to Free on the due date.
Repo Size Limit Increases
Should a user request a temporary extension of the size limit of their repository the following workflow should be used if that extension is granted.
Open an issue in the dotcom-internal issue tracker using the Repo Size Limit issue template.
Using your GitLab.com admin account navigate to the project in question while appending /edit to the URL. For example, if the project in question is located at https://gitlab.com/group/subgroup/project/ you would navigate to https://gitlab.com/group/subgroup/project/edit.
Enter a new value in the Repository size limit (MB) field.
Click Save changes.
Revert the size limit back to the default of 10GB on the specified due date.
Customers may ask that a project they recently marked for deletion be deleted immediately so that they can reuse that project's path without needing to wait. Should a customer request this through Zendesk, do the following.
Open an issue in the dotcom-internal issue tracker using the Soft-Deleted Project issue template.
Fill in the details of the template and submit the issue.
Add a link to the issue to the Zendesk ticket and inform the customer that we've asked an engineer to process the deletion.
GitLab Gold Requests
Issues that come in with the GitLab Gold Request label require no action on our part as the process of granting Gold to the namespaces specified within them is entirely automated.