GitLab Incubation Engineering - Latest, 6 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

This is the March 2023 Showcase for GitLab Service Desk SEG. We released native attachments for Service Desk emails, which allows external participants to receive uploads to a comment as a native email attachment. We also decided to deprecate the sidekiq delivery method for mail_room email ingestion in favor of the webhook delivery method. I made progress on custom email verification, including a new verification model, a move to a dedicated model for email credentials and merge requests for three verification email.

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

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:26 Native attachments for Service Desk emails
0:54 Deprecate sidekiq delivery method
2:28 Progress on custom email verification
4:55 Goals

A

Hi, my name is Mark I'm. The signal engineer group project lab service desk, and this is the March showcase.

A

The service desk signage new group is all about providing a complete, yet lightweight customer support solution that seamlessly integrates with the gitlab ecosystem and brings customer support staff and developers close together native attachments for service desk emails. Allow external participants, like the issue, offered to receive uploads to comment as a native email attachment.

A

The feature has been released in gitlab 15.10 in general availability and was featured with a secondary release post item in the Milestone release. Post I started work on removing the feature flag, but I will need to take some dedicated time in the upcoming weeks to get this merged. Gitlab ingests emails using a separate process called mailroom.

A

We added a new delivery method, called webhook to transport emails from the main room process to gitlab a while ago. The idea is to push the email contents to the gitlab backend through an internal API, endpoint authentication Works via share token. The API controller then schedules the job to process the email.

A

The team's plan was to remove the over delivery method called sidekick, but that never happened using the sidekick delivery method is discouraged because it directly writes to the redis queue that we use for background job management. Additionally, email bodies are quite large job payloads and we cannot compress them this way. There are also other disadvantages of this approach. Therefore, we should deprecate sidekick and remove it later on in multi-node, setups customers often fall back to sidekick because it's easy to set up, so we need to provide an alternative once we we move it.

A

A few weeks ago, I proposed to move email ingestion from mayroom right into gitlab and use sidekick worker jobs to ingest emails, and this is likely to be the successor of the sidekick delivery method for mayroom.

A

After some discussion with support colleagues and project management, we decided to deprecate the sidekick delivery method for May room in 16.0 and schedule it for removal in 17.0 I, put out a match request that adds the deprecation notice for 16.0, and we also have a good discussion about updating the documentation for deliver method options in general and now I want to give you an overview of my progress on custom, email, verification.

A

The new verification model has been merged, it adds all feeds related to the custom email verification process in a dedicated table. The merge request to move custom email credentials to a dedicated model has also been merged. Based on user feedback. We will need to deliver IMAP and Omni auth for Microsoft graph ingestion methods sooner than later. So it does not make sense to pollute the service desk settings table with credentials that we rarely request. Instead, it's better to have it in a separate model.

A

It's great that this has been merged, because this was a blocker for other merge requests. Also, the custom email verification triggered email has been merged. This merge request added some helper methods and the notification email project owners and the triggering user will receive once a verification process has been started. The email looks like this.

A

This is the HTML version, and this is the plain text version, the custom, email, verification result. Email is also in review. Once. The verification process is finished, we'll send out the result. This can be a successful error message with details to all project owners and the user who triggered the process.

A

There are several states of this email, and here are some examples. When everything works fine, you will receive this success message when we cannot establish a connection to your SMTP host. You will receive this one.

A

If you provide invalid credentials, it will look like this and if your service provider does not preserve the original email from header, you will receive an error like this. So there are other error cases, but this is just an example: collection and the actual custom email verification, email is also in review. Gitlab will try to send this email with the provided, SMTP credentials to a special sub address of your custom email along with a verification token. This email is not intended for humans, but for your gitlab instance.

A

If everything is set up correctly, we can ingest this email check the token, the from header and so on and verify the custom email.

A

This is how the email looks like this is a text only email without translated text, so I missed both of my goals for this month, but made good progress on the verification for this one use, interviews and feedback made me decide to do refactoring and move the credential to their own table. This much request had a great and important discussion about SMTP address validation and that delayed other merge requests. Building on top of the stains I did some experimentation in the UI, but then tried to push emails forward as much as possible.

A

So my goals for the upcoming month since it's holiday season in Germany I will also have reduced capacity in April and we won't have a mid-month update. Video in April I want to have all verification, Parts out in merchant quests and hopefully soon merged. So that's it for my side. Thank you for watching and take care and see you soon.