Handling Internal Requests

NOTE: If you are a GitLab team member who wants to file an internal request, please see the Support Internal Requests handbook page.

NOTE: For internal requests relating to licenses and subscriptions, please refer to the relevant license and subscription workflow, or CustomersDot console workflow.

Overview

This document details the various templates and workflows that should be followed in order to properly handle 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:

• Admin Escalation
• Dotcom Escalation Weekly Report

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.

General Workflow

graph TD;
  A[Issue Created]-->B[Assign Yourself];
  B-->C[Issue Actionable?];
  C-->J[No];
  J-->K[Apply Status::Blocked and Inform Submitter];
  C-->D[Yes];
  D-->E[Take Action];
  E-->F[Issue Resolved?];
  F-->G[Yes];
  G-->H[Close, or Apply Status::Awaiting Confirmation and inform submitter];
  F-->I[No];
  I-->L[Requires waiting?];
  L-->M[Yes];
  M-->N[Apply Status::On-Hold and set due date];
  L-->O[No];
  O-->P[Escalate as necessary];

Activate Trial Runners

For sales assisted trials, only we can override the credit card validation requirement for a namespace. See Internal Requests > SaaS Trial Related > Change an existing SaaS trial plan for instructions on how to perform this task.

GitLab.com Trial Change Request

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.

Ask for Support as a Solution Architect

Solution Architects should use the Support Super form only when support is needed during pre-sales (for example: a POV exercise, or a potential new deal with an existing customer). This form is an internal request, which means the work takes place between the SA and the engineer. Customers can not collaborate on these tickets. In any other cases, SAs should advise the customer to open a support ticket themselves, for clear and efficient communication.

Inactive Namespace Request

GitLab Team Members can no longer submit inactive namespace / namesquatting requests for their own use. See: support-team-meta#5170

Customers can submit a support ticket. See Name Squatting Policy.

Contact Request

GitLab team members should use the Contact Request template to request Support to contact a user on their behalf.

Usually, these are assigned to CMOC, but can also be completed by anyone with admin-level access to GitLab.com. Admin Escalation label is applied and everyone with admin access is supposed to be subscribed and working on such issues.

See the Sending notices workflow for complete instructions on how to contact users.

Repo Size Limit Increases

At times, users require an increase to the size limit of their repository as a workaround for a bug issue. In these cases:

1. Open an issue in the internal-requests issue tracker using the Repo Size Limit issue template.
   • If you do not have GitLab.com admin access, add the Admin escalation label. If needed, post in the #support_gitlab-com Slack channel for attention on it.
2. If a request is a workaround to a bug issue:
   • Use current size + small buffer (2-5 GB) for the exception size.
   • Set a due date for reverting, up to 1 week from current date.
   • If a longer exception time is required, add the Manager Approval::Required label, and post in the #support_leadership channel to request approval.
   • Make sure to comment on (or create) a bug issue to help future users and prevent further tickets.
3. Apply the Status::On Hold label and set the due date to when it should be reverted.
4. 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.
5. Enter a new value in the Repository size limit (MB) field.
6. Click Save changes.
7. On the specified due date, revert the size limit back to the default by removing the value.

Pipeline Quota Reset

See internal wiki page.

GitLab.com Console Escalation

There is a generic template used to request an engineer with GitLab.com console access to take action.

Before submitting a console escalation request, ensure that you perform Account Ownership Verification workflow for the following types of customer request:

1. To extract and release information.
2. To make changes to account(s).

This ensures that the request is coming from an authorized contact. Console escalation requests for internal investigation do not require account verification. See Support Team Meta #5276 on the discussion.

Common issues include the following when the UI and API methods are not working:

• Deletion of projects, groups, cluster integrations, container registry images, etc.
• User account confirmation retrigger
• Project export

Rarely, console escalations will also be used to workaround lack of a feature where Support can complete actions that would be unavailable or onerously time-consuming to customers. When actions cannot be done via the UI or API, engineers should ensure that a feature request exists to have it in the product. Consider tagging the appropriate Product Manager for prioritization.

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. For example, searching for unverified secondary email until gitlab#367823 is resolved. 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.

Any request requiring assistance from infrastructure teams, please see the SaaS Platforms Request for Help issue tracker and SaaS Platforms Getting Assistance page.

Response time and escalating the request

Support engineers with console training and access are subscribed to the “Console Escalation::GitLab.com” label, and one of them should respond within 1 business day. If you need to reach out to the group, you can do so by mentioning the console group. Please note that there is a read-write group for requests that require write access. If it’s urgent, please ping the specific team members who are working based on timezone in the #support_gitlab-com Slack channel. If none are available, please engage infra SRE on-call and notify the Support Manager on-call for awareness.

Fulfilling console requests

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. You can filter requests by “Read::Only” or “Read::Write” labels. Common or custom functions can be found in the support runbooks.

For update, create, and delete actions, it’s essential to carefully review the request and think about the impact of these actions. Remember, update and delete actions can be risky. When writing custom commands or scripts, it’s crucial to calibrate them based on the potential risks and the situation’s specifics. You should always get another set of eyes on your code to confirm what you want to achieve. Customer data loss is not an acceptable tradeoff for expediency.

If you’re not completely sure about the specifics of the script or commands, test them out in your test instance first. And if needed, get feedback from developers who know that area of codebase before using them in the production console. This approach helps reduce risks when doing console tasks in production. For any scripts that are originating from the support team and are not already in a runbook or approved by development teams, please reach out to a manager or staff support engineer for review and approval.

CI Catalog Badge requests

CI Catalog Badge requests are to be actioned by a Support Stable Counterpart for Pipeline Authoring. These requests are used to give certain organizations a “Partner badge” in the CI catalog on GitLab.com. They require a GitLab.com administrator account to execute the verifiedNamespaceCreate GraphQL mutation.

1. Open GraphiQL with your GitLab.com administrator account

2. In the following query, replace root-level-group with the namespace and verification level (GITLAB_PARTNER_MAINTAINED, VERIFIED_CREATOR_MAINTAINED) provided in the internal request:

   mutation {
     verifiedNamespaceCreate(input: { namespacePath: "root-level-group",
       verificationLevel: GITLAB_PARTNER_MAINTAINED
       }) {
       errors
     }
   }
   

3. Execute the query via GraphiQL

   • In case of an error, reach out in #g_pipeline-authoring for assistance

4. When closing the internal request as actioned on, ping the requester to let them know the badge was applied

View page source - Edit this page - please contribute.