 Okay, so thank you, thank you for waiting. We start today's functional group update from CICD team. We had to reschedule the last week update. Thanks, Jakob, for switching and doing front-end one instead. Maybe let's start with accomplishments. The last functional group update was between 9.4 and 9.5. And we actually managed to do a lot of 4.9.4, much less 4.9.5 due to vacations. We basically merged 75 team managers for 9.4 and 31 for 9.5. But what is more important is the features that we ship. We ship a lot of very important features like a lot of improvements to CA variables that makes much easier to automate your CICD projects by specifying group levels, specifying schedule, and a lot of that is EEPremium features, cross-project variables and environment-specific variables. For example, cross-project variables will be shipped with 9.5. Also, we merge security improvements like blocking pipeline jobs on protected branches. We merge some community improvements allowing you to specify configuration paths of your CICD file, but also some annoying bugs that a lot of people were facing at github.com and not only is this bug we cannot connect to CI server error message, but 9.5 is also some research project, not really research project, it's like research of the feature that we plan to do beyond 10.0 is proof of concept of job block, a few also later. And also Alessio Kaiser joined our team starting yesterday we see that as big accomplishment. But as always, there are lowlights, a few things that slipped partially because of lack of the hands to do proper testing, partially due to communication issues. These are the main things, Autodeploy 0.20, it's probably the biggest one that it slipped and it did slip for the second time. We actually miss merge window due to basically inability to make sure that everything that is part of Autodeploy is in a good shape and can be shipped with github. Autodeploy is basically connected with a lot of issues that are very important for 10.0 that gonna be released next month. Basically flattening configuration enabling auto devops, auto CI, this is what I'm gonna talk about a little later. Migrate CID status for stages, we did a lot of work on the preparing migrant migrations, but for some reason we didn't manage that in time. We started discussing protected runners, we had some good ideas how to implement that, but it did not happen either. Our supplement is for runners, this is something that is in play for some time, not yet being done. If we talk about 10.0, we are always ambitious. You can, for example, click the CI CD board for CE and EE for 10.0 to just see what we are currently working on. Like the biggest, I think, the most important part of the 10.0 you probably get that from the kickoff is Autodevops. And Autodevops is like our direction, not only for 10.0, but also for a few upcoming releases. But not only Autodevops, but there's also a lot of security changes and improvements, some performance, some customer support requests that are, we know that are being voted for some time already. And 10.0 is just a great time to do major changes and duplications. So we just do something that we should do a very long time ago, is just rename all occurrences of GitLab CI multi-runner to be GitLab runner everywhere. Because this is actually GitLab runner, not GitLab CI multi-runner today. And also duplications of all CI API, something that we are waiting everybody for some time, renaming code climate to code quality because this is more appropriate word to be used. But 10.0 is just a start of new era for the CI CD team and we are looking way beyond 10.0. I mentioned about Autodevops. If you are very interested about that, just click this link and you will see much more information about Autodevops. Basically Autodevops is like an ability for us to offer users very good user experience when using CI CD of GitLab by providing you auto build, auto CI, auto deploy, auto code quality, auto monitoring, we allow you to have this great and boring thing experience. There are some ideas what we can use. For example, for Autocci is the Heroku build packs for testing Heroku introduced build packs very long time ago, but sometime recently they introduced test packs. Actually this is extension to build packs that allows you to test your projects. It seems like the great idea to be used for this web-based projects that we gonna promote with Autodevops. Heroku-based projects that we play very nice with auto CI and auto deploy and we be like the great solution for Autodevops. But Autocci is not only about preparing you to improve onboarding, but also allowing you to have this implied configuration for everyone. Currently we enable CI CD for everyone, for every new project that is created, but we don't run anything because most of these projects doesn't have GitLab CI.yaml. With 10.0 we just plan to ship the first iteration of this GitLab CI configuration that will be used always. This is the configuration that will be built in into GitLab, but this will be the configuration that you can basically copy, improve and use in your project if you really need. But there will be always some configuration used if you have the CI CD enabled. The big, another move is just GKE integration. We are looking very, very into Kubernetes. Allowing you to create a Kubernetes clusters, install runners, improve the CD parts. So basically Autodevops of experience. We are looking into grouping everything, making it possible to configure everything on group level, like runners, Kubernetes clusters. We introduced variables recently. This is one of these steps to make it happen. We also see that there are some problems with the future scalability of CI CD part, like the size of the CI beats table. We just want to make sure that the stable is effectively stored and that we store metadata in the best possible way, that we have ability to archive some metadata and to make sure that we can scale today to also work in one year from now when we have, let's say, 10 times or 100 times more data than we have today. Configuration improvements. This is something that is also quite requested even by people at GitLab. For example, only X upon five part is one of these very interesting features. For example, if you prepare a documentation change, you don't really need to recompile everything, run any aspect or just RuboCop tests because you only want to link your documentation. So only expect this is one of the improvements that we are planning and we plan to ship. Ux improvements. This is something that is happening constantly and there is a lot of people working on that. For example, in the last release, we try to evaluate a feasibility of improving the job log. One of the reasons to improve the job log is that the job log is usually the place where you go when you see the failure and the current experience behind the job log it's kind of lacking compared to other CI services out there. For example, ability for people to easily find the relevant information for the failure, ability for people to figure out a to get a link to a place in job log, which is relevant and you can copy paste it but also ability to easily go through pipeline ground to job log. Something that is right now very complicated because you have to go to pipeline graph, click a link, you go to another page, then if you want to see another job in another stage, you have to go back and click again. This is the experience that is not very nice today. So we try to do proof of concept. Something I think it's not very widely used at GitLab but like proof of concept where the idea is to move fast, don't care about that quality because we have in mind that this is not something that we're gonna use for the final product but at least we can quickly test our assumptions about that feature. And for example, how performant it is if we were to implement that feature. CI on GitLab.com. Last time I mentioned about Bitcoin miners, this is like kind of ongoing and never ending story and there is like a lot of efforts from Brian here, our security lead and also from Thomas who are basically who and they are basically like introducing another mechanism for blocking Bitcoin miners. They are becoming more and more annoying basically every day and we just now in their face of figuring out what else we can do, what else we can implement in order to block them. I will not disclose any details about what we are doing. If you are interested, just click the first link. This is the confidential issue because we don't want to show everything what we are doing because this is publicly visible. Move artifacts to object storage. This is something that has been implemented but it now waits for execution. Execution production site and make sure that it works well. CI production readiness. There are a number of things being done and a number of things that are, we are continuing to work on. The end goal is basically to have the HA solution of our infrastructure. So not be really dependent on single infrastructure provider as we are today. This is something that we should be able to achieve once we introduce permittious monitoring for owners. Something that is actually taking some time today to be done. I think that that's it for today. I will happily read questions. Group configuration will be huge for many large customers. Yes, we think the same. This is something that is like being, it's actually the toy job that you have to configure some configurations on per project basis instead of allowing you to be configured on group level, especially that we have today subgroups. One of these examples you could think of is just runners. You just have your set runners for your group basically, not for the GitLab instance. Will that be an EEP feature? Some of that probably yes, but not all of that. Today, for example, group variables are CE feature, but we just resolve these cases, these use cases case by case. And then we make the decision whether this is EEP, EES or CE. Group configuration, we don't yet have plans for doing that. We did actually discuss that a number of times. It's not really a scaling issue. It's more like the ordering of the actions to be done with us with everything. Okay, I'm not seeing any more questions. If you have any other questions, just ask in either general questions or CICD channel and we will be happy to answer. Thank you, see you on the team call.