For GitLab team members wanting to file an internal request, please see the Support Internal Requests handbook page.
This document details the various templates and workflows that should be followed in order to properly service GitLab.com related requests that Support receives in the internal-requests issue tracker.
Internal requests can and should be addressed by any GitLab Support team member who is able to resolve the request.
Those who are at least 50% SaaS focused and have a GitLab.com administrator account should subscribe to and handle any issue that is an Admin Escalation.
Internal requests are typically created by other team members who are not within the Support organization, but you can always create an internal request to track work being done, especially in cases where the request originates internally (and there is no ZenDesk ticket to track).
At the very least, you should subscribe to the following labels:
You may want to consider subscribing to Platform::SaaS but be aware this will be noisier.
By subscribing to the labels, you'll receive notifications on when a request is created. You should try to work them into your regular workflow, ensuring that you are assigning it to yourself like a customer ticket if you decide to take it.
If you are interested in servicing internal requests that require console access, consider speaking with your manager about completing the Gitlab.com Console module.
For sales assisted trials, only we can override the credit card validation requirement for a namespace. Note that there is a special process for consumption users. These requests require console access.
Sales team members will typically open this on behalf of their prospects in order to extend an active trial. You can follow the L&R Workflow for Extending Trials.
GitLab team members can create this request for their own use or on behalf of their customers. See Name Squatting Policy.
GitLab team members, primarily infra, will use this template to request Support to contact a user on their behalf. If requested to do this via Slack, open an issue on behalf of the requester.
The requestor should contact the CMOC to fulfill the request.
This typically requires GitLab.com admin access, because you will need to look up the relevant email addresses.
See the Sending notices workflow for more details. If none of the listed cases apply, you can use the
Support::SaaS::Notices::General Contact Request macro. Leave an internal note with a link to the issue.
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.
Repo Size Limitissue template.
Status::On Holdlabel and set the due date to when it should be reverted.
See internal wiki page.
This is a generic template used to request an engineer with GitLab.com console access to take action.
Common issues include the following when the UI and API methods are not working:
Console escalation requests can also serve a purpose when further information (unavailable through the UI or API) is needed to understand the root cause of a problem. This may be because we are not sufficiently logging in Kibana/Sentry, we're unable to replicate an issue, or the creation of an issue may not be the appropriate action needed to resolve a customer problem. Collaborate with console enabled engineers and product teams to solve these types of problems.
Engineers with console access should search for similar previous requests, look for the relevant function in the code, or work with another engineer to resolve each request. Common or custom functions can be found in the support runbooks.
Any request requiring disk access requires an infra issue.