 Well, I guess we can get things kicked off. Well, thanks everyone for joining the kickoff for 11.8. I'm Jeremy Watson from the product team here at GitLab, really excited to get things started. So let me go ahead and share my screen and we can start chatting through items. Cool, you should be able to see my screen. So from the managed side of the DevOps lifecycle, I have a couple of items that I wanted to talk through. The first one is being able to add LDAP, the smart card authentication strategy we introduced in 11.6. So we wanna be able to allow users to interact with GitLab using a hardware token, like a Ubiqui. And we added the ability to do this locally in 11.6. We wanna extend that and allow you to connect with this, with an LDAP server and authenticate your hardware token against that. The other addition that I'm really excited about is displaying last activity and created at times, actually in the user's panel, in the admin panel. One of the things that admins kind of typically a question they need to answer is when users kind of join GitLab and when they were last active on the instance. And we wanna be able to make that a very easy question to answer by putting that information directly in the user's panel. I'll come back to this after we hear from Victor and plan Victor over to you. Thanks Jeremy, quickly sharing my screen here. And so on the plan side, we have a couple of really exciting things as well. So this is a feature that we started on last cycle and then we're really close to being finished and basically being able to move horizontally in time in the roadmap view. So basically you can see in the screenshot here, you have a roadmap and just being able to grow back and forth, scrolling back and forth in time. So that's something that's very intuitive and we've wanted to add for a long time. And we're really excited to ship that very likely in 11.8. In 11.7, we've added the ability to have ethics of epics and so basically child epics or nested epics, however you wanna call it. And what we're doing in 11.8 is allowing you to reorder the epics. So let me show you that very quickly here. An example here is you have an epic and right now you can reorder these issues and with that epics of epics, you can do exactly the same thing, reordering the epics in your list. So you can use that order to imply some priority order sorting or whatever your order is per your particular team process. We're also cleaning up the API, so allowing you to have the reordering itself and also having epics of epics in the API. We're going to allow same activity filter option to the backend for epics. So again, what that means really quickly is just this particular option here. Let me pull up the epic really quickly here. Right here, this show activity here for an issue, we have exactly the same thing for epics and we're gonna allow you to store that and persist that on the backend. So wherever you log into GitLab, you will have that setting saved. Starting a discussion from a non-discussion comment, it's a bit of a mouthful, but essentially we wanted to have threads in GitLab and you already have this in GitLab if you'll notice but the feature is a little bit hard to use because you have to start typing here and you have to decide that it's gonna be a discussion thread in the beginning. So just like many different systems like Slack and other apps, you can take an existing comment and then start a thread with that. We're gonna allow that inside GitLab as well. So that's very exciting. Folks have requested that. We're gonna have an updated design for the related merge requests inside an issue. So right now inside an issue, if you look at any issue, you will have a list of merge requests at the bottom of right below the description right here. So you related issues and then related merge requests. So the really merge requests will follow pretty much the same design and so right now related merge requests are just lines of links without any Chrome. We'll improve that so it looks like related issues. And finally, we're going to allow folks to create a merge request inside the Jira Issue Development Panel itself. So the Jira Issue Development Panel is a really helpful integration inside every Jira issue if you've connected to GitLab and we wanted to allow folks to be able to create a merge request right from the, a GitLab merge request right from inside the Jira Development Panel. Jeremy, back to you. Thanks, Victor. Let me share my screen again. Cool, you should be able to see my screen. So I'm filling in for the create team and I have five really exciting changes that I wanna talk about. And the first is mirroring changes from the Web IDE to the CI runner. So we added interactive web terminals in 11.3 but when you use them with the Web IDE there are a few challenges. The code that you're interacting with actually is related to your most recent commit. So whatever changes that you're running in the Web IDE might not be reflected in the banner. So we're actually gonna solve this 11.8 by mirroring those changes so that whatever code you're interacting with or whatever state is in the Web IDE is what you see in the terminal. I'm really excited about this and should make diagnosing those issues in the IDE very, very easy. The second thing I'm excited about is requiring approval by code owners. So we previously added code owners to GitLab projects to be able to identify who are the experts in a particular area of your code base. In 11.8 we're actually gonna add a merge request option to the project settings to require at least one approval from those code owners before that merge request actually gets merged. I'm really excited to see this addition. Of the few other items that we're adding is the simple change to expand a diff to an entire file. So one issue of merge requests is that you need to actually browse away from the merge request itself to view very large files. And we simply wanna be able to make that easy to do in the merge request. So we're simply adding a button to allow you to expand the full file directly in the merge request to remove the need to browse away and simply show the entire file right there in that view. We'll also continue to iterate on suggested changes. So previously suggested changes could only be done one line at a time. And we're expanding our syntax to be able to allow you to replace multiple lines in a single allowed line change. And finally, I'm excited about this relatively simple change which is simply being able to override the squash commit message when you squash and merge. Typically what will happen when you squash and merge is a very informative commit message will get actually overwritten by several fix up messages that you might have added previously. And now you'll be able to override that and make sure that when you squash and merge, you'll have a very informative comment that'll be a commit message that'll be retained so you'll know exactly what this is all about. So that's all from create. Jason, over to you. Hey everybody. So let me get my screen shared here. All right. So for verify, we have these three items here which I'll quickly take you through. The first is that we're implementing a new pipeline dashboard view which will be a customizable view that lets you see all of the pipelines that are running across any number of projects or groups of projects that you might like. This will be a configurable thing where you can choose what you're wanting to look at and it'll show you and now this is a mock up of course. So this may change a bit but it'll show you which pipelines have passed if any downstreams have run or are in play and whether they have passed or not and you failed and so you can build a dashboard here that will let you see for all the projects that you care about what the at a glance status is and if there's anything that you need to take a look at. We're also delivering the cross project trigger ability. So not much to show on this one but if anyone is doing cross project triggers right now you know that you're making a curl command to call the API to do the trigger. So now we'll have a native syntax for that and then features like this next one recursively expanding the upstream and downstream pipeline we'll be able to take advantage of that. Now this is a feature that's already coming in 11.7 but what we're adding here on this animation is that you can go infinitely in either direction. So if you have pipelines that trigger pipelines that trigger pipelines that trigger pipelines you can explore all the way through those pipelines and see everything that was triggered and you can kind of explore all the different branches of how those are triggered as well. So with that back to you Josh. Thanks Jason, that's pretty exciting. On the package side we have a number of kind of minor items we're working on but also we're working to include packages now in project import export. Previously they weren't included and so if you're exporting your projects they were not included and so we want to make sure they're included in there and so going forward from that eight we'll have those added to the files that are generated from the UI to make sure you can easily transport your projects around without losing some of your packages. Jason back to you for release. All right, thanks Josh. I'll get my screen share one more time. So for release we also have three items. Two about pages and another one here. So the first item on the list is we're adding support for subgroups to pages. This will allow you to set up pages using a URL that will look something like this for pages projects within a subgroup. This is a very, very highly requested feature so we're very, very excited to be delivering this one. We're also improving our feature flags feature, the ability to manage feature flags within GitLab for your code by adding the ability to set the feature flag on or off on a per environment basis. For example, it might look something like this where you've got your production environment where the flag is off and then stage off as well QA environments and then your non-protected environments are on. There are some mock-ups in here but these are a bit earlier. We're gonna be finalizing these in the next day or two. But it'll be something like a matrix that gives you control over how you wanna turn these things on and off in your various environments. And then finally, enabling access control for pages on gitlab.com. We added the access control for pages feature, a release or two back. So this is making that now available on gitlab.com. What this will let you do is control who has access to the pages that you're publishing. So if you're doing something like publishing private documentation or publishing a private website, you could control access through this means and with this change you'll be able to do it on gitlab.com. So back to you, Daniel. Thank you, Jason. Let me share my screen here. So the Configure team is excited to take back up the work on the ability to upgrade the runner application when it's deployed via the Kubernetes integration. So currently once you deploy apps via the Kubernetes integration, there's no way to upgrade them. And basically what we want to do here is that we'll show you the current version of the app that is running. And when the newest version is released, we'll upgrade it automatically for you. And we hope that the method that we use for this particular app will be the one that we use for the rest of the apps. So we'll update them as new versions are released. So we'll do it for the runner in this particular release and then we'll do it for the other apps in the future. The next thing that we're going to work on is moving the auto-devops domain from where it currently sits in the CI CD settings and we'll move it to the cluster settings. So basically as you know right now, if you go to the CI CD settings for your project, we're going to be able to set up the domain for auto-devops. That's great. However, if you have multiple clusters, setting up multiple domains is not intuitive and it has to be done kind of through variables. And yeah, it's kind of a little cumbersome. So basically when we take it back to the cluster settings, you're going to be able to just set up the base domain right there as you're setting up the environment scope of the cluster and you're seeing the apps. So that's going to be there using that with multiple clusters a lot easier. The next thing that we're going to work on is giving you more control around the configurability of auto-devops and more specifically the ability to disable it at the user space level for GitLab.com. So if you're a GitLab.com user, and let's say you have hundreds of projects and for some reason you don't want to use auto-devops, you would have to currently disable them individually. So this will give you the ability to disable them for the entire user space for GitLab.com, providing you more control over its configuration. The next thing that we're going to work on is going to be increased security for the Jupyter Hub deployment when used via the Kubernetes integration. So basically what this will allow you to do is whenever you deploy Jupyter Hub via the Kubernetes integration in one of your projects, only members of the group that the project belongs to will be able to log in via GitLab authentication when logging into Jupyter Hub, basically providing you with increased security. And then the last thing that we're going to work on is something that was announced by our CEO, Sid, a couple of weeks ago in our blog post, and that is that we are moving chat ops to core. So chat ops is currently an ultimate feature, but we see that it has a lot of usage by individuals, developers, operators. So we really want to bring that feature set and all the power that it brings to core, and we'll be working on doing that as part of this release. And that does it for the Configure team and Josh, onto you for Monitor. Thank you, Daniel. That's really exciting to be able to bring that to core. Let me go ahead and get my screen share. So hopefully that's coming through now. We have a few exciting items here on the Monitor site. The first one is we want to enhance our operations dashboard feature to also include the pipeline status. Currently it looks like this, and we'll be enhancing this to also give you visibility into what the current or last pipeline is, whether it's running or failed or past. This can be important if you're waiting for deploy, or if you want to get a quick idea if your, for example, master is currently read. This can give you that quick at a glance view of that portion of your projects and how healthy your CI is, which is always really important to know. The next item, we've been working on a new chart library for our metrics dashboard. We're currently using D3, and we're switching over to Echarts. And this release, we've been able to, we should be able to essentially hit parity with the features we have in D3, and we'll be able to turn it on for everyone currently it's behind a future flag. So that'd be very exciting to get that enabled and get some benefits as well as increased velocity going forward with a higher level chart for our team. The next one we're working on is a nice user enhancement here where if you're using custom metrics, currently we don't do validation on the query. So we'll now be doing validation on the query and informing you if the query is valid or not. And this'll give you quicker feedback here when working with the Prankwell queries than if you had to wait and try to go to the dashboard and then see it failed. So it's a nice little user improvement there to help improve the ability to add queries to the dashboard. The next item again is a similar UX improvement to our center integration. And so we're launching that here in about two weeks it's probably about seven. And what we're doing here is enabling an easier way to connect it to your project. And so currently you have to kind of know the API URL to your project with the right endpoint, but we're able to build some additional integration here with the API to then simply give a host, get your center URL for the host name, now token, and we can then go ahead and give you a list of projects which you want to then tie into. So it'd be much easier to go ahead and configure this than it currently will be with 11.7. So that'd be very nice to go ahead and configure that. The next item we have is we're going to be improving the metrics output of the GitLab registry. So the embedded registry within GitLab does perform this monitoring, but it does not turn on all the box. And so we'll go ahead and get that enabled for folks. And then the final item here we want to do is you want to also support alerts from external Prometheus servers. So right now we have support for alerts from the managed Prometheus service that we deploy through the Kubernetes cluster integration. And we want to expand out support for having GitLab be aware of alert status for Prometheus services that you might manage by yourself. And so we're going to go ahead and get that done here in 11.7. So some extra options for us. Fabio, why don't you tell us about what you're doing with secure? Yeah, thank you, Josh. And let's take a look at the plan for the security in 11.8. So let's start with the option for users to set the group level dashboard as the default view for a group. That's very important because if you are a security professional, if you are a director of security, when you go to a group, you probably want to access the dashboard as the very first entry point for your flow. With the current implementation, you have to go on a group home page and then click on the security dashboard all the time for every group you want to take a look. With this new behavior, you can set for your personal profile, your user profile, the ability to jump exactly to the security dashboard as soon as you reach the group home page. So there will be the default behavior that will still get the access to the details of the group. But if you set that option, you will see the group level dashboard. So that's in order to support people that are in the security teams in that new role that we want to support at GLAB during this year. We have also another improvement for the security dashboard. And we already have a chart showing you the history of vulnerabilities for your specific group. At the moment of the timeframe, what you can look at is a fixed one, is a 28 days timeframe. But we know that people may want to dig it more and see maybe three months or half a year in one single view. So in 11.8, we're gonna improve this view, this chart and add the option to change this here in the chart itself. So you will have a way to set different timeframes to better fit your analysis needs. We are also working on something that is not, so nice to look at from a visual point of view about very, very interesting and important that is the SAST for JavaScript. At the moment, our SAST tool supports Node.js only. It doesn't support generic JavaScript projects. We want to improve the support and include the generic JavaScript as well. And the last thing is create confidential issues from vulnerabilities. When you create a vulnerability from the security dashboard or from a security report, this issue is a regular GitHub issue. So based on the visibility of a project, the content could be more public than expected. And since this content contains all the details about the vulnerability, it's probably something you don't want to disclose until you have a fix. This also fits well with our internal process. So when we have a report, a security report, the issue is kept confidential until we have a patch. So we can release the patch and then disclose the information to the community, to the public. So in 11.8, we are gonna change the behavior and when you create a niche, it will be confidential by default. Obviously you can turn it to be public when you're ready to disclose it. So that's both to support our internal flow and also because it makes a lot of sense for other users. And that's it for Secure. Josh, back to you for the distribution team. Thanks, Fabio. We have a few items here for distribution. And the first one is we want to go ahead and test out cross-plane for the provisioning of object storage and data provisioning for our cloud native GitHub Helm chart. This is really exciting since cross-plane should provide a multi-cloud option to kind of provisioning some of the services or pets that you might want to utilize with GitLab. So databases, Redis clusters and things like that. And so we can leverage cross-printed to kind of do integration once and have that work across a variety of clusters as opposed to trying to build something that is cloud-specific into GitLab. And so we'll be giving that a try here in this release and hopefully we can get that marriage to make it easier for folks to deploy sort of a enterprise, more robust version of GitLab utilizing some of these sort of pets outside of a Kubernetes cluster that might not be quite ready for it like a database. Next one is we want to make it possible to configure and enable the smart card or cac authentication for GitLab. So this was presently on the bus package recently and we want to go ahead and make it configurable for the GitLab versions of political netties as well, our Helm chart. We also want to make it easier to support GCS buckets when configuring backups and other tasks in the task runner for the GitLab Kubernetes Helm chart. Presently, it's not as easy as it could be. And so we want to make sure that it is kind of on par with other bucket options that we have within the product. And finally, we've been working a little bit on this is to, we'll continue so one that eight, we should be able to ship this in this version which is to switch our GK micro place over from a previous deployment solution to a more robust one based on Helm tiller, which will enable easier maintenance going forward for things like updating parameters or upgrading versions as well. So much easier to perform kind of ongoing maintenance on deployments of the GK marketplace once we get onto this new base image for the deployer. So some very exciting features here coming up in 11.8. Thank you so much for joining our kickoff. It's really exciting. I can't wait to see these features ship and launch and also stay tuned in two weeks for our 11.7 version being available. Thank you everyone and have a great day.