GitLab Incubation Engineering - Latest, 13 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering - Service Desk - May 2023 Showcase

Description

Showcase-Issue: https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/13

Find all videos in the playlist of the Service Desk SEG:
https://www.youtube.com/playlist?list=PL05JrBw4t0KoB04jd7TCRs9AHOms3hVsZ

You can find all resources on the Service Desk SEG handbook page :
https://about.gitlab.com/handbook/engineering/incubation/service-desk/

Please subscribe to this GitLab issue if you would like to receive notifications for all future updates:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/3

Additionally, you may have a look at the feature exploration issue:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/2

If you want to learn more about Incubation Engineering at GitLab, please visit
https://about.gitlab.com/handbook/engineering/incubation/

Chapters
0:00 Intro
0:16 Service Desk updates
1:03 Custom email address
2:48 Email ingestion
5:07 AI
6:15 Goals

A

Hi, my name is Mark I'm, an incubation engineer here at gitlab, and this is the service desk single engineer, group May, showcase.

A

I know it's been a while we had holiday season in Germany and I also took some time off so I think we have a few things to discuss. We had a bug in Native attachments for service desk, and this has been fixed and shipped in gitlab 16.0. The service desk email had the wrong content type when you use the new node template for service desk and added an attachment to a comment. We also work together on adding two new placeholders for service desk issue templates and updated the docs accordingly.

A

Now we have issue description which prints the complete description of the newly created issue and issue URL, which prints the URL for the newly created issue. This works in both thank you, email and new node email, so Micron focuses custom email addresses for service desk as a first iteration I work on delivering a mode where the administrators set up email, forwarding from the custom email address to the configured gitlab incoming email address and, on the other hand, provides SMTP credentials so that we can send service test emails from that mailbox.

A

I already mentioned all the emails that are needed for verification to work properly and all the verification emails have been merged now, so the verification triggered email, the verification result, email and the actual actual verification, email, Additionally, the verification, State machine has been merged. We saved the state of the verification to the database and use a state machine to Move It from one state to another.

A

For instance, we only want to have a verification token in the started State and not when it's finished or when it failed. Additionally, we're verification, create service and update Services have been merged. This is the logic part of the custom, email, verification the create service, tries to send the verification, email and adds the database record. We use to keep track of the verification State.

A

The update service then takes the ingested verification, email and checks whether the token matches the form address is the same as the expected one and the email has been received in the defined time frame. We do this to ensure the mailbox supports all the features. We need to check that the email forwarding has been configured correctly and to verify ownership.

A

There's a last bit missing: we need to call the update service when the verification email has been ingested, so I'm planning to deliver this shortly. Next I'd like to talk about email ingestion in general, gitlab users can submit new issues and comments via email administrators configure special mailboxes that gitlab pulls on a regular basis and fetches new unread emails based on the slug and the hash in the sub-addressing part of the email address. We determine whether this email will file an issue, add in service desk issue or a comment to an existing issue.

A

Right now, emails are ingested by a separate process called mailroom. We offer two delivery methods that push fetched emails from that separate process to the gitlab backend. The webhook delivery method is the currently recommended setup, my room posts, the email to an internal API endpoint that selects the correct Handler worker and schedules it for execution.

A

This sidekick delivery method directly adds emails to the redis queue that sidekick uses to manage jobs. It has been deprecated since gitlab 16.0 for many reasons, either the deprecation node with more background information and a guide on what administrators should do now. A multi-node setup is where gitlab is run across multiple servers for those setups. With the Linux package, Omnibus installations, we recommend running email ingestion only on OneNote, we added an extensive documentation section that works administrators through the steps and configuration options in one of the previous videos.

A

I talked about a proposal to replace the separate email ingestion process with an internal sidekick job I recently added a merge request for a first version of an architecture, blueprint which is still in review and not yet published.

A

This design documented as part of the architecture Evolution workflow, which we use to push forward. Bigger architecture, changes and improvements in this document, I walk you through the email address in general, the current setup with the two delivery methods and our motivation to have a scalable solution that will also allow custom email address ingestion in the second part of the document. You can explore the proposed solution and the execution plan.

A

We still need to discuss some details and I will add a few review suggestions in the next couple of days. We already have great AI experiments in our software and we don't want to stop here, so we are also thinking about where I or machine learning in general can help in the service desk space. We currently investigate in finding similar issues or work items.

A

A possible approach is that a gitlab bot user will add an internal comment with a list of related or similar issues or work items. That's very useful for projects with a lot of work items you can easily connect related work items and even find duplicates in the context of service desk. You could also find similar services or related work items from your issue tracker. We also have an internal use case for our support. Ops Team. We currently explore content-based recommendation and can probably use parts of our custom model.

A

Tanuki stand that auto labels issues in a schedule pipeline we'll also test you using embeddings of issue content where we'd compute, the vector distance of the issues and an input and select the issues that are nearest to the input. I'll dig deeper into this in the following weeks and discuss details with the AI teams, so my goals for the rest of the current month, I'd like to discuss custom email settings page with product design and I'd like to dig deeper into finding similar issues. That's it for today take care and see you soon.