 All right, welcome everyone to today's functional group day for the platform backend team. My name is Dao Man and I'm the engineering manager for this team. And today I'd like to run you through what we've been working on the last five weeks and what we plan to get on in the next five. And as always with functional group updates, it's all about the questions you guys have to ask. I'm sure you've already reviewed the slides. If you haven't yet, they are in the chat, a link to them is in the chat. So if there's anything you'd like to, you know, get some clarification on that's what we can spend these following 30 minutes on or less if there's nothing. So in the last five weeks, first of all, we finalized development of GitLab 10.5 on the seventh and then we started development of GitLab 10.6 on the eighth. I'm gonna talk about GitLab 10.6 a little bit more in the next slide, but I'd like to quickly recap at 10.5 and specifically what the platform backend team contributed to this. Of course, there's a lot in that release, both platform stuff and stuff other teams worked on, but here are five issues that I'd like to specifically call out. And I'd like to thank those people for working on those. First of all, Git LFS to file locking support. Of course, Git LFS supported Git LFS for a while, but Git LFS to edit file locking support where you can lock access to specific file on the command line. GitLab already supported file locking as kind of our own solution in the web interface. And now we also support Git LFS to file locking and it interacts as you would expect with our own web interface based file locking. If you lock a file in the command line using Git LFS, it will also be locked in the interface and the other way around. So thanks Ruben who worked on that for 10.5. And then the next one push to create a new project. This is a feature that I am probably unreasonably excited about, but it's just really cool. If you starting a new project locally and you have your whole get set up and you have your first couple of commits before now, if you wanted to make that into an actual GitLab project, you wanted to share it with people, you'd need to contact switch between your terminal and the browser and you need to follow the flow there to create that project. And now you can do that by just pushing to a non-existent project URL. If you're pushing to an existing namespace, so that's your own personal namespace or a group that you're a master or an owner of, if you're pushing into that, we will automatically create a project for you as a private project. So you don't accidentally leak any data. And then of course, you can always go into the web interface and switch it to public, but it's private by default. And this can definitely save some time if you just wanna get your little project up onto GitLab instead of it being on your local machine. Thanks, Tiago, who worked on that. We also added proper LFS support when uploading a file through the web interface. Of course, we've supported LFS for a while, I just mentioned that, but there was a bug that had been around for a while which was that if you upload a file through the web interface, it would be added in the repo as a concrete file, no matter how big it was and no matter what the LFS policy said about certain file extensions needing to be in LFS rather than right in the repo for infine 10.5 when you fix this. So thank you, James, Edward Jones, who worked on that. We also added the ability to transfer a single group to another group. Like I mentioned in the last FGU, this is something that Myra actually worked on in her as part of her application to GitLab when she was trying to join the company, which of course she did and she finished this issue that she had worked on back then, which means that subgroups just became a little bit more powerful because now you can actually easily move to a subgroup-based hierarchy from a simple single-layer hierarchy you might have had before by transferring one group into another level in that hierarchy. We also fixed a number of bug and security issues that I specifically like to point out just because it's 11 out of the 23 issues we put in 10.5. And I think a 50-50 ratio of features to bug and security fixes is worth mentioning. If you wanna read about all of the other stuff that went into those, in the 10.5 you can follow the link to more. If you are a community member who's viewing that link, you might see a lower count of what I just called out because some of these issues are still confidential, which means only GitLab team members can view them, but this should also change over the next couple of days as these issues are opened up. That's the last five weeks. If you have any questions, feel free to post them. Don says he was surprised to see LFS file locking messages from Pushing. Nice work. I think that message, I don't know if it's file locking. Oh, yeah, right. Someone locked the file in GitLab CE at some point and then we had to unlock it. Anyway, that's all good. No, actually it's like when you push LFS objects, then you can configure Git to also do the LFS file locking and you have to configure Git correctly to make that work with GitLab as a whole. Oh, okay. You can do it automatically with Git LFS. I was not even aware of that, but thanks, Tom. At least I'm happy that you find it nice work, even though I wasn't aware of the specific thing you were calling out as having been added. Anyway, in the next five weeks, first of all, we plan to finalize the development of GitLab 10.6 on the seventh and release in the 22nd. And there's gonna be a lot of stuff in this contributed by platform. The first two here are things we already worked on for 10.5 and they were very close to done for 10.5 but because they have pretty big security implications, we wanted to give them a little bit more time to be super, super confident about them not accidentally opening up any holes and us having to scramble to patch those in 10.5 patch releases. So we decided to push both at 10.6 and both of them are, one of them was already merged and the other one is gonna get merged soon. So 10.6 will bring both of those features. The third one is a new feature or at least it's not a new feature, but it's a feature that we are newly developing for 10.6 which is allow the modification of a fork merge request branch by project maintainers. What this means is that if you were submitting a merge request from a fork to an upstream project or from a fork of GitLab CE through the actual GitLab CE repo, the creator of that merge request will now be able to say that maintainers or project members of the canonical repository GitLab org.GitLab CE are able to make small changes or changes of any size inside the source branch of that merge request which means that if they wanna fix a simple typo or for example, they wanna retry a filled pipeline where they wanna fix a rubocop issue because they saw that there was some code style issue, they can fix it themselves pretty quickly rather than instead of having to go to that person wait for them to make that change which can add hours or days to the whole review cycle. So this will definitely save some time and that's gonna go into 10.6. We're also adding group and project badges. These are badges like the ones for CI status, code quality, those kind of things, little badges that you often see in project repeats. We are making these kind of a first class citizen on the project homepage. So you will see these by the project title on the product description, you will see a list of these badges and these can be configured on both the project level and the group level and if you configure one at the group level it will automatically be visible on any project inside that group. And of course these will be configured with a URL with some placeholders for certain parameters like the actual project name, the latest branch, the commit shaft, the latest branch, et cetera. So that the external system that we are calling out to get that little image will be able to load the latest data and present that to us. Next we are adding API endpoints for importing and exporting projects. Importing and exporting projects, these are features that we've supported for a while through the web interface if you went into the admin or the settings area of your project. And now we are adding APIs to the exact same thing. So you'll be able to export a project which gives you a TGC file and then you can upload the same project TGC file through the API to create a new project out of it. And of course the idea is that this would happen into different kid lab instances. So this means that you can automate, automatically moving a project from one instance to the other and it's kind of an alternative to mirroring if for whatever reason, you're not able to have just direct connection between the two servers having them talk to each other directly. You can export on one side and import on the other through some side channel of, it doesn't really matter to us how the data gets from A to D but this will solve that particularly in this case. We are also going to add CI CD for external projects. This means that you will be able to create a project inside kid lab that has all the features disabled except for continuous integration and I think it's employment, CI CD pipeline features and it will automatically update itself based on an external repo like on GitHub or BitPocket or another kid lab instances for some reason we'd like to set it up that way. And it's a couple of sub issues specifically we are going to automatically trigger a kid lab mirror update when kid have received a push. Right now, if you set up a kid lab project to be a mirror, that means that it will on a schedule automatically pull new data from the remote side but this will be on a schedule which means that it's not quite real time depending of course on when inside that schedule period the push happens on the GitHub side of things or the side of things on the other server. Of course, GitHub supports webbooks as well. So we will automatically set up a webbook on GitHub which will tell kid lab, hey, I just got an update which will immediately trigger that kid lab pool mirroring update. The other one is also really interesting kid lab CI CD status inside kid have projects. This means that if kid lab CI CD pipelines run and they fail or they succeed or they have a warning or they do anything of the things that pipelines can do, we will automatically update the GitHub project on the other side with that little status information about the commit. So this will be displayed inside to get help pool requests inside the GitHub anywhere where they show these commit statuses. So that means that you can use kid lab CI and get up in combination if you for whatever reason want to stay with GitHub for certain features but you really want to make use of those awesome features that kid lab CI CD has. And the third one that platform is working on which is a sub issue of the CI CD stuff is the option to override those virtual branches when pool mirroring. Right now if you set up a project on kid lab to be a pool mirror of some external project if you then make a change in one of the branches on the kid lab side of things just add a commit or you rewrite something we will not automatically update that branch with new data on the remote side of things because we don't want accidentally delete the data that you know the commits that you might have added locally because we don't want you to lose that data but we will add an option to toggle between the override behavior and the ignore behavior which is currently the only option and which is still going to be the default but of course if we're doing CI CD or personal projects you automatically want to mirror every branch that is changed on the remote side of things you want to pool in all the changes even if the local branch diverges. Of course there's a lot more that we are doing for 10.6 and if you follow that little link you'll be able to find the list of deliverables for 10.6 or platform. And if you follow the development link at the very top you'll also see our issue board so you can follow along right with the team how we are progressing issues from backlog yet to be picked up all the way to close and you can kind of see where we are at as far into the model. And then on March 8th we are gonna kick off development of kid lab 10.7 and if you'd like to know what's gonna be in that release I recommend you join the public kick off on that 8th of March which is open to the public as always. Like I mentioned last couple of times I actually don't know quite what's gonna go into 10.7 yet. We will try to finalize that over the next two weeks or so. All right, looks like some questions shut up in the chat. Bren and Larry asks when 10.6 is released and group level assembled us that mean it will immediately be available on kidlab.com for customers or are there any additional steps after that? It will be part of a specific kidlab.com plan. I'm not completely sure which some of the product should be able to clarify that but then once the feature is released people will be able to link that kidlab.com group to a SAML server and they'll be able to use it to sign in. But we have, as we always do at kidlab we split up the whole kidlab.com SAML thing into multiple stages so the whole feature won't look and feel complete until one or two releases into the future but with 10.6 it will at least be able to link your account up and to sign in using SAML which is kind of the first iteration. If you wanna see the details about what we're bringing today and what's gonna be in 10.7 or 10.8 you can follow the link to that issue and we'll describe that in more detail. Lyle asked about a few current customers interested in the answer to this. Well, yeah, there's your answer and if anything's still unclear also feel free to go into that issue and ask me or any of the product people or the developer works on it what the deal is and exactly what you can expect in the first release. Oh, okay. It will actually be limited behind the 10.6. Well, there you go. I'm working with outdated information but I'm glad that James was able to clarify that. Remy says badges are cool and Philipp says this is going to be used to migrate gymnasium users. Yeah, that's talking about the CI CD for external project stuff. Gymnasium users who are using gymnasium with their GitHub account currently will be able to migrate using GitHub with GitLab CI CD and then inside GitLab CI CD gymnasium will be running effectively which means that those people can stay in GitHub and we can slowly start to convince them to come over to GitLab with all the other features that we have to offer. Okay, if there's nothing else then I'd like to thank you all for your time and you get about 20 or 17 more minutes of your days left. Thanks everyone. Have a great day.