 All right, happy release day everybody. This is the Edge Group update for August 22nd. I'm Robert Spiker, I'm a developer on the Edge team. I'll be talking about what we've been working on since the last update. And what we're working on going forward and later Christian will update us on what he's been working on on Git itself. So let's get started. Because the project is so central to just about everything GitLab does, we create a lot of them during our automated tests. Previously, every project that got created came with a real popular Git repository unless you explicitly said you didn't need one. Most of our tests don't need one. For example, if we're testing issues, those need to be associated to a project but they never touch the repository. We've now inverted this, so you only get a repository if you explicitly ask for one. Creating a project without a repository is about two times faster than creating one with it. So this was a good change across the entire board. Similarly, every project we created also created two users. One for the namespace the project belongs to and one for the creator of the project itself. Now instead we piggyback on the namespace user record and just reuse that as the creator. This results into your database records across the entire suite. For example, in this one example, there's 253 in a single spec. While we were making those two changes, we discovered that whenever a project factory needed a repository, we were actually setting it up a second time for no reason. So we decided to stop doing that. Our longest reigning champion for slowest test file, which just yesterday took 45 minutes. While we were building the final RC was reworked and now performs the exact same tests in just over three minutes. We now keep track of flaky specs. So when a test fails, but then passes on the automatic retry, we mark it as flaky. This is a big first step to preventing new ones from being introduced as well as removing the ones we already have, which are the bane of our developer's productivity. Blackstone from the core team, as well as Alexander Ronda have continued to convert spinach tests to our spec features. Our goal is to eventually convert all spinach tests and only have our spec tests, mostly because there's some separation and duplication around the infrastructure for the two suites that we want to eliminate and spinach tests are just more of a pain to work with in general. We now take advantage of cache policies in our own CI configuration. The one job doesn't modify the cache that it downloads at the start of the job. We don't waste time uploading it unchanged at the end of the job. Change log entries are now categorized and grouped by types such as bug fix, new feature, security fix. This is a personal highlight for me because it was the first time someone besides me added something to our change log generator, which means my code wasn't totally insightful and terrible. So thanks, Jacobo, from the community for that. Genshin added a handy linter that detects conflict markers so that when we don't accidentally leave any behind during the CE to e-merge, for example, this is really good for docs which don't get compiled and we might leave those behind without noticing. York added another custom Rubikop rule that helps us prevent us from creating slow migrations plus a new merge request template so we don't forget something when we make database changes and also more database-related documentation which is always appreciated. We merged 36 test-related merge requests and 82 community contributions in 9.5. That's really a lot of community contributions, especially when you consider that everyone goes through the same review process that ours do. Genshin started to organize our e-only files into a top level directory for better code separation, which will continue to help reduce the number of conflicts in the daily CE to e-merge. And now I'll hand it over to Christian and I'll talk about what he's working on in Git itself. Hi, everyone. So I've been working on external or DB support on Git itself since May last year. So what we want to do is nearly the same as Git LFS, but without the need to use another command, you would need only Git itself. So it's based on previous work that Jeff King started in 2012. And it's more generic because you use helpers, which are external commands. And in fact, they only need to implement the init instruction. And they could also implement some gate or put instructions or have instructions, but it's more modular and it can do other things as you will see later. So it's performed thanks to work from last Schneider on the Git filters, which are used by Git LFS by the way. So we take advantage of this work that was done for Git LFS. And also from work from Ben Peart. So Ben Peart is working for Microsoft. They have been working on something called GVFS. I don't know if some of you saw the presentation they gave at the last Git merge conference. So it was about that. So some of their work has been integrated into this work to make it faster. And so, yeah, so there is the possibility to forget, to get or to give, objects that are blobs. In fact, in different formats, either the war blobs or the Git objects, which are blobs that have been compressed and a header has been added. Or the helper can also access by itself the Git loose objects or the Git files. And either put new objects in them or just get objects from them. So there are three different modes to make it more generic. And also it can be used to have restartable clones, which is a problem that some people have complained for a long time about. So, yeah, because as it's very generic, it can do more things. I don't know if we can see the second slide now, Robert. Yeah, thanks. Okay, so I submitted a presentation so I submitted five versions. The last one on August three was the first one that was not an RFC one because I think it's good enough to really build on it. And I think the reviews have been good. So, and if you are interested, you can get the documentation in one of the patch I sent. So there is a link. And hopefully what I hope is that it will be merged before the end of this year. That's it. Okay, thanks Christian. So for what's next, we want to replace factory girl create calls with build stubbed everywhere we can since it doesn't hit the database and it's just way faster. For most objects that belong to a project such as issues and merge requests, we can piggyback on the project owner record instead of creating a new user record for the author, for example. We're still looking into that. And currently we treat the unit test for the notification service class as more of an integration test for the class that builds a list of recipients. I'll spare you all the boring details, but it's by far our slowest test now and we can definitely make it faster, but it's complex. So if you're interested, there's more details in the issue link there. Does anybody have any questions? Let me look at the chat. No questions there? Yeah, 45 minutes to three minutes is a big difference. All right, I guess that's it. Thanks everybody. 20 minutes.