 Hi everyone, can you hear me? That's fine. I think that you should be able to. So nice to meet you. And nice to meet you on the Functional Group Update of the CI CD team. And just to let you know, we recently changed the name from the CI team to CI CD team. We are very proud of that change pretty much. But basically when we started creating this presentation this morning, I thought that everyone can contribute, right? So I actually did create this template for this presentation and ask the rest of the team to actually feel that we've content. And this is basically what they did came up as a first slide that my point zero will be the best release ever. So it seems that they are very proud of what they achieved pretty much. So I would only confirm that we just shift some crazy amount of things that I'm just, it just feels unbelievable for me. The amount of work that we spent on making 9.0 happen. This are the highlights of 9.0 in terms of the CI. This is crazy. This is amount of the performance, UX, UI, front and back end polishes is just crazy. I just go through the maybe most interesting ones. We had this performance regression, maybe not regression, performance deficiency on an environments page. Something that you have to actually ask about www.github.com environments is actually not opening. And it was just because when we were designing this view we forgot about adding pagination. It's kind of a really terrible idea in the end. But this is solved. There is pagination in environments. This view is fast again. And we also added a few new additions to this view. Because right now we also have folders. You can go to review folder and see all your review apps in that single place. But also if Enterprise Edition Premium you also have deploy boards now. So you can see live status of your deployment when it's actually being run on Kubernetes. And with 9.1 you will also see canary deployed on this view. So it's just because we did it, it opens so much flexibility in how we can improve what we actually ship there. And this is something that's the second very interesting feature or back depends. We engineers consider this as a feature. Customers consider this as a back. We had this back or feature for five months and customers started asking us that it doesn't make sense. We should just have a pipeline that is blocking. If you have an action in your pipeline on some stage it's the action that it's blocking and not really something that should be skipped and we should not consider then a pipeline has succeeded. 90.0 pretty much solved this issue. Because right now you can choose whatever you want. You can have blocking and non-blocking. You can mark an actions that are non-blocking like cleanup, stop preview. And they will just be skipped. They will just not be accounted towards pipeline status. They will be just be executed but they will not fail your pipeline. You can have an production deployment to be blocking that you will just not merge or do anything if you're pipeline unless you actually click this beautiful play button. And the another big thing that actually is also very interesting from various of the other reasons. For a really long time, and we also have, it's not really yet fully completed, we Github CA Runner was basically generating crazy amount of requests. I believe it was something like three millions one hour probably something like that. And with 9.0 we managed to ship that with great help of Andrew, with great help of Kim, Jacob and a bunch of other people that were working on making this happen. And it's life. It's actually, but the truth is behind the story that it opened us a possibility with also the CI depreciation changes for 9.0, open us a possibility to actually kill the support for old runners with the API V3 depreciation period. And this is actually the ultimate goal because long pulling works, long pulling makes GitLab Runner to ask basically GitLab, GitLab writes every once hour. But we still have this crazy amount of the old runners that are still using the old technique. If you look, for example, at this graph, you can clearly see when we enabled long pulling. This drop on this not found ready is hit. It's basically new runners were using this technique. But what did happen afterwards? We just unleashed so much computing power afterwards that the old runners just started consuming more and more resources as you would expect, right? And until we don't kill old runners, we just have problem or we just don't slow the old runners. We just have the problem with old runners that they are still generating a lot of, a lot of load on GitLab.com. All new runners, runners basically since version 1.9 are supporting long pulling. And this is actually something that we have also from manual testing. We also see that on graphs that this is actually paying off and it's working. But there are always low lights, unfortunately. And one of the slow lights, we have this back report. People that are kind of annoyed of emails for success pipelines. Probably I think that most of you actually get along with that by creating spam filters maybe or something like that. But not everyone has this opportunity to do it like that. But this is something that we actually trying now to solve as part of 9.1. And we are working with the discussion team we've shown Genshin and Sean and me together. We are working on solving finally this long issue. There is also problem of growing container registry. We have long term plan on making this solved. But I don't know, band aid or intermediate solutions are not yet there and they are not working properly at least from my test. This is something still yet to figure out how to do properly. But maybe there is actually one bigger low light from the last couple of weeks is actually the stability of the short rumors. We ship so many new things. We ship so many new additions to the process that we kind of wake up in a new reality. And this new reality actually creates this storm of things failing crazy. And this is actually something that was seen in recent days. And we had the problems with long job queues. We had the problems with specific runners not picking jobs. Some of these problems they are not yet resolved. We are actively looking in solving them. Some of them are resolved. But basically this actually kind of open part of much bigger conversation that we as a CICD team tried to open and make everyone to be aware. It's about the changes that we have to introduce for CI on github.com. One of the changes that you probably heard about this is short runners minutes. It's our way to actually make sure that we can control amount of the jobs that are run on github.com. But the truth is that we need to face much bigger challenges in upcoming months. For example, every time that I see that there is some problem with the CI, I basically learned that. The first thing that I have to check, I have to check if there is no person mining bitcoins for example on github.com. We had so many of these kind of projects already that is just crazy. So basically one of the challenges I think for upcoming months is actually to define what it does mean to actually be a fair, what it does mean to have a fair usage on github.com. What is our retention policy? How we actually for how long we store your artifacts, we store your container images and how we monitor runners. But also there is one thing that we are actively working right now on is visibility and also resilience and documentation of how things are working. Thing is that github.ci and github.com are very complex. They are consists of multiple components. We have github.com, this coordinator, we have artifacts storage, we have container registry, we have runners, machines, docker and join. We have infrastructure provider. We run these builds externally. There are also security concerns. This is a lot of moving parts. And over time it did show that each of these parts could basically break at some point. Creating better documentation, making people more aware. Also creating with our hands some training for the team. I believe that it will help everyone on triaging these kind of issues. Concerts, as always, we are actively looking for new people. The front end, front end senior backend for race and go. We could achieve so much more if you would have just more people. But we also very strict and also our expectations are very high for potential candidates. And this is actually one of the reasons why it's taking this amount of time to find new people. But this is 9.0. This is our concerts. This is things that they are happening, that we are working, constantly improving, making sure that we are aware of that and making sure that we increase this visibility. But there are also our plans for 9.1. You probably saw already most of them at kickoff. This is just part of them. I'm not sure if it's actually very interesting to go into details because you can just simply click on each of these links and see what is under the description. There is so many areas in the CI and CD space and also in idea to production space that we are working and we are improving. But I'm just very looking forward for 9.1 to be even better released than ever. So thank you very much for the attention and I would happily look for questions. I only see lower community contributions and best release ever. Okay, thank you very much. It was very quick and see you in 15 minutes.