 Welcome everyone to the second session of the KitLab Hackathon. I'm thrilled to be joined here by Tony Klaas from the GEO team. He's going to be doing an introduction on the GDK, the KitLab Development Kit, to essentially tell us how to get started, how to do your first merge proposal, and how to essentially make sure that you've got all the tools required to run your code. He'll be doing a live session, and in the end we will have some time for questions. If you have any more questions, you can always ask them on githubhq.im.com and we'll be happy to answer them. And with that, Tony, I'll let you take the stage. Yeah, good morning, or good afternoon, or whatever where you are. Welcome to the session. I'm going to quickly try to set you up with GDK and show you how easy it should be to work with GDK. So I'll be sharing my screen to just show you that. Okay, normally you will be able to see my screen showing the welcome page of the KitLab Development Kit. That's good. So let's just head over to the readme and see how to use it. Basically, there are two steps. First, you need to prepare your computer, and this means you have to install a bunch of dependencies. We have documentation on various operating systems like OSX, still weird that's OSX, you may get macOS or whatever, and also different Linux distributions, and I'm not sure about Windows. I don't think that's how it's experimental to do that with a subsystem for Windows. There are different setups for all those. Among the team, we have different people using different OSS, so most of them should be supported really good. Next up is to set up your GDK. This is basically just a few commands to get you started. So I have to install the gem that we are using to use for the KitLab Development Kit, and it's basically just a gem. So when you have installed your when you have you prepared your computer, you make sure you have Ruby installed, and with Ruby installed, you can easily install the gem. So this would be the basic command to install just any GDK. If you want to specify the directory where you want the GDK to be, then you can use this command. So I'll copy that. I'll make just a demo directory and go there and create my GDK CE to develop on KitLab CE. After that, you need to go in there. I'm not sure that might be documented not too good. And what you will do then is to clone the KitLab CE project for yourself. And when you want to contribute, you have to fork the KitLab CE project. If you go to the KitLab CE project over here, you can press the fork button. Select for which user you want to create a fork. And then KitLab will create a fork on your name. So now don't get lab CE will be created. That would be the repository you want to push your code to when you're done with your GDK, with your changes you've made. For the purpose of demonstration, I'm going to use a quick variant of GDK install. And we're just using a cloning from a local directory. So that avoids me from cloning from the web, which is from local directory is much more faster. But usually you will just use this command to run it from your fork. So this takes a while. So let's not wait for that for this moment. So it does run the installation. For some reason, this is complaining about my Ruby version not being correct. I think we have a bug there that was recently introduced, but we can skip it for now. I'll be working on this later this week, I guess. And what it does, it sets up like everything, all the services you need for your GitLab to run. So it will prepare this part, it will pair your GitLab.yaml configuration file with some same defaults. It will install all the gems it needs for GitLab CE. After that, it will also install the NPM dependencies using yarn. And at this moment, it's compiling the internationalization files for all the different languages, which I think we have another session about internationalization later on. So if you're interested in that, please join that. And it will also set up other dependencies like Workhorse, which is basically some web service we use in between GitLab CE and the web. But this installation also takes a while because the installation is not that slow, but later on it will also seek your GDK with some testing data. So you don't have to create everything from scratch, it just provides you with a setup that's not empty. So at this moment, it's creating a database schema. So to skip that, we don't have to wait for that. I have another GDK I have already running here. Maybe I'll just be not too fast and just look at the readme first. So yeah, when you're developing in the fork, also run this command. And this will ensure that you set the upstream remote in your repository. So your origin remote will be your fork. And the upstream remote will be the canonical repository that is the official one which you want to eventually have your code merged into. And this little command will help you with that. We're not interested in GitLab enterprises at this moment, so let's go back to the readme now. Meantime we see that the schema was created and now it's seeding all the data for GDK. So how do you use that GDK? So when this command would be done, it will be finished and you'll be able to use it. So how do you use it? It's not in here. I expected it to be here. It's weird I expected it to be here, but basically it's very simple. You just, it will show you how you basically would just run GDK run in the directory GDK CE. And then it will sort all services you need like Postgres, like Giddly, like their background processes, Webpack is also providing you for your JavaScript dependencies and things like that. And this also takes like a minute to start because there's some dependencies and it needs to load the whole of the Rails app. But when you do, and that's what it also says at the top, it will make your GitLab, local GitLab available, local host port 3000. So when we go there, you have the GitLab running on your local host. And basically it's that easy. So you run GDK install and you just run it and then you're good to go. Yeah, the password is not listed here, but you can log in with root and the password is five live, which is documented everywhere in the documentation. And then you'll be able to sign in in your local, I made a typo. And that's it. See, here are some projects that's being seeded by this process over here, like a GitLab test. So it has a code for GitLab tests. It has some issues and some word requests. So you have some data you can get started with to test out your local GDK. That's what you need to develop on your GDK. Now, when you want to develop something, you start off with issues. We already shared the link for the accepting merge request issues somewhere already. And basically, this is a list of like 500 issues that should be really easy to pick up. There are a bunch of them over documentation. We have another session later today about contributing to the documentation, which you might be interested if you want just to documentation because it's really easy and you probably don't need GDK to contribute to that. But in this case, we really want to make a code contribution. And I've picked an issue that is hopefully fairly easy to demonstrate. So this is an issue that already also has the accepting merge request label. And let me quickly explain what the problem is. So there is a slash command or a quick action, sorry, that allows you to do copy metadata from one issue to another or to merge request. And I can demonstrate it over here. So I have issue one, and I can label it. Oh, we don't have labels yet. Okay, just create some labels first. Generate the default set of labels. Okay, back to the issues. So issue one, let's label it with a bug. Command is applied. So when we refresh the page, we'll see it as the label bug. When we open another issue, so we added that issue one. And for sale, like it has the same labels, it has to have the same labels as issue one. We can use the slash command copy metadata, list the issue like number one and comment that. When we refresh the page and see that the label bug is added because it was also added to label to issue one. Now, in case we want to create a new issue, we say this is a new issue. Copy the data data. You see the copy made a data command is not autocompleted. So that's an indication that it's not working. And when we just type it anyway, we submit the issue. And we see this issue doesn't have any labels. So that's the bug we are trying to fix now. Now you're interested in, luckily for us, in this issue, Sean McGiverin already posted where the change should be made. As we can find the link again. So over here, here's a link to the code that handles this. So you can see the copy made a data comment. Only can be executed when the issue bull, so the issue that you're creating is persisted. But because you are creating a new issue, it's not persisted yet. So that's why that command, the copy made a data command, is not enabled when you're creating a new issue. But in fact, there's no reason that it should be persistent at the time you're creating the issue. So we can just remove this line. So let me just get started. Copy. As you can see, when the server is finished, you also see gdk run is being mentioned also. Sorry, for my context, which but back to my gdk. Now that's this gdk that was still seeding, which has completed. And now at the end, when it has done installing, it says you how to use your git lab, you get gdk. So you can just run gdk run or only the database when you just run the test or the app when you want separate processes for the database and the app, which is the Rails app. Another interesting command here is gdk update, which updates all the dependencies in your gdk setup. So all the services and git lab rails, everything is being updated so you can continue when you haven't been using gdk for a while. Sometimes you also need to run gdk reconfigure when you mention after the updates some things are going wrong. It might be safe to just run this and then it will update your settings back to how gdk expects them to be. And over here is also the login for the root account on your gdk. So let me just move over. So you want to develop your git lab directory. So let me just open the directory in my editor. So over here, this is the coach tree of git lab, the Rails part of it. So if you're familiar with Rails, you'll recognize the app directory, the library directory, and for specs, for tests, your inspect directory. There are a lot of different interesting directories, but we'll focus on those right now. So for chains, you'll probably want to start off creating a new branch for your feature. Just take it, branch, check out and then B to create a branch. So we created a new branch because we wanted to push that branch later on to git lab. Then the file was this one. I linked it from the ishable with this button. It copies the popular clipboard and then when you search, copy metadata, here's the command and here is the line that was the problem. So it's very easy. There are just one condition. If you can update the issue, just, it's good enough for the condition. I'm not sure why that happened, but whatever. So I removed the line and git lab reloads those things instantly. So basically, I mean, just when we create a new issue, I'm not sure why actually. Okay, we're here now. So let's just create another issue. Let's copy. You see, at this moment already, the command is completing. You can select the issue you want to copy from and submit the issue. Let's see if that works. We have the bug label. Yay, the bug is fixed already. But we won't accept these things like this because we really like to have some tests on this code. So this is important to have tests on it. So we're in the directory app services, quick actions. And basically, you would find the same directory structure in spec. So in spec, that's the directory. In your git lab, you find it's also the service directory and the quick actions directory. And also here's already a file for the interface service. Let's see if there's also a test for the copyrighted data command. Yes. Oh, seems to be more complicated than I expected. But oh, no, this isn't. So this set of shared examples, because we are using these tests on issues and on merge requests. So we want to we use those tests for both things. So you don't need to duplicate the code. Let's see if there's something that tests if the issue could persist. And maybe it's just easier to see if the the tests are present already. Do they succeed without like without doing changes? So if I do bundle exec spec, our spec, so bundle exec, our spec, back services, quick actions, this file. And that's the command you have to run to run a single file for tests. And it's a little bit of time to set the start get started, to load the Rails application, and then it will be running our tests. And because it's first time is to set up git lab shell from scratch. And after this also gaitly, I think so it will take like a minute or two. In the meantime, David, are there any questions or something we want to get into or other participants or we want to raise a question or something like that? I haven't seen any questions on GitHub, but I actually have a few. So I mean, first of all, I'd be interested to know, I mean, is the gtk something that's used on only on particular cases? Or does the whole team, the whole engineering team at git lab use gtk when developing? Well, that's a good question, because I, and that's very interesting. I think, like, most of the developers or most people who write code in git lab use gtk. So that's a good thing about it. It's constantly maintained, because it also has to work for itself. So it's not a side project that outside contributors sometimes use and that breaks very often. No, that's not the case. It works because we use it ourselves. Cool. So yeah, I mean, that's, yeah, I mean, I think that's also good for contributors, contributors as well in the sense that, I mean, not only what you're saying, but also they're using consistently what you guys are using for, for the development. That's good. So when you get started, you mentioned a couple of commands. It's essentially gtk install, gtk run, and then perhaps gtk update. Are there any other commands that you can think of that might be interesting for developers or for new comments? Well, those commands do most of the things you need to do, especially when you're not a contributor that consumes a lot of time. Let me just quickly check which commands there are. So there's like a database, you can run geodatabase with that only applicable for geo when you're, and that's an enterprise edition feature for premium. So you're probably not interested in that. I haven't been using myself on my gtk yet. Ten is something else if you want to run web servers. Some people use it, but that's not, yeah. So most things here are not that important if you want to contribute irregularly. There are some things because gtk uses a make file and there are a lot of commons in there. You can run them individually, but most people don't need them. Okay, cool. And then on the, so in terms of other things that you might want to run, I mean, I think quite follow how you run the test, the testing here. You run just an individual test or did you run the whole test suite? No, no, that's it. Yeah. So I just run one file. Okay. So basically for each file in the application directory of Rails, we also usually have a file in the Spectre directory. So basically just a one on one mapping. Also for like more front end stuff, there are also integration tests who are just using like really pushing buttons on the UI to test if the flow is working correctly. And those are more like feature-wise and not so file-based, but that's something else. The merchant coaches will help you out if you need it. Okay, cool. But that would essentially run all of the tests on that file, right? Yeah, this does. So in this case, I want to use the copy meta data command command. And you can run a subset of tests in that file by using the column syntax. Let me just find a good line to do that. All right. Yeah, it doesn't test the changes on the issue itself. So don't test updates. Just copy some stuff over. So I see for MerchantQuest, that's not persistent. So that's not yet created in a database. You cannot use the slash quick action, which totally makes sense because yeah, you cannot merge the MerchantQuest test not created yet. So it has to fail when you do that. And it creates, it does that by creating an issuable and it builds that issuable. So it doesn't create it, but it builds it. And the difference between create and build is that it does not, when it built, it does not create it in the database. So I can copy over this line. And then back to the copy meta data command. The haves like empty. The haves like not sure. So when I go back to my, so let me just bevert my change at this moment. And I think so I added this piece of test. And this is the piece I want to test. And it's at line 863. I can run it like this. So specify the line you want to test behind the column. And I think at this, I hope at this point, my test will fail, will succeed, because I want to have, when I do copy meta data, to do nothing, behave like empty command, when the issuable is not persisted. So when I'm building a new issue, and it's not safe to the database yet, and I'm having the copy meta data command in the issuable, then it won't do anything. So this succeeds. Perfect. With my change, so let me just convert it, save this file, go back to the test case, because I don't specify the issuable source issuable. I have to do it like this. So I did use a copy meta data command, but I didn't specify an issuable, so it couldn't copy any data. So that's the reason why it... So let me just rephrase it again. So I create a source issuable, which has a few labels. I run to run the copy meta data command from that issuable and I'm doing that on an issuable that's not persisted in the database yet. And this succeeds. That's very weird, because it shouldn't. Okay, I'm not doing very well here at the moment. No worries. I think it's good for people to see the iteration process as well. So the issuable, it should update the label. I'm not sure why. At least this should also succeed. I'm doing the exact same, then this case. So why don't we imagine it can be converted to a good mill. It's probably because my issu is not persisted yet. So this shared test is not built for that to match the way it updates. Okay, so it's the process. So what I'm will be doing now is do a binding to apply here and that will stop my debugger at this line. Which will make, which will make it easy for me to see what's happening here. We have got some documentation on, well, a bunch of documentation, to be honest, on development, which are pretty extensive. So in our doc directory, there's development directory, which has a with me. And here are a bunch of stuff about different features inside the GitLab source code three, how to do some, some debugging, some testing, some writing tests, writing markdown, also internationalization, things like that. There's a lot in there. So if you're interested in some topic like database debugging, there are different documents about that. And there's also a topic about prior debugging, which is basically the debugger we use for Ruby for our Ruby on Rails project. And like it says is place finding the price somewhere in your code. That's what I just did. I just placed it here inside my test. So now I'm running the test and my debugger did not stop there. What? Because I added a line also that changed my line where my which piece of code I want to run. That's the downside of specifying a line of code in your file. And prior is very extensive. You should check out the prior wiki page because there's really, really, really a lot of features and there are some listed here in this document. But if you want to see them all, then you'll probably want to browse through the wiki of that project. So at this point, here is my debugger stop. So I can run this line by doing the next and my debugger will step over it. No, it doesn't step over. Okay, it's step into whatever. That's also good. So the issue is the issue I just created. But as you can see, it doesn't have an ID. So it's not persisted in a database yet. And then you can finish this function. And then it steps back into my test. And now I can see the updates. They're empty. For some reason, the service does not include any updates. So it would have been useful if we would have done this. So let me just stop this test and want to begin and step into the service execute. And that's the reason why the test did fail because it wanted the key had label IDs from updates. And that's an empty array. That's a nil, so it filled in that. So next, let's step into next, next, next comments. There's one comment in there and it says copy metadata issue one. Let's step into the extra updates comment. Let's step into each. And next, what is the definition? You can print the value of that here. Copy. So that's that's a quick action for copy metadata. And you have to specify an issue or merge request. And our demands is issue one. So basically that should work. So why isn't it working? Step into the execute of this definition. Is noob set? No, it isn't. Is available context. So we have an exit here, I think, because it's not available. So step into the move. Step into available. Condition block was the value of that. It's set. So it's next context instance. So it will run the condition block to see if we can run this. And I think I've figured out why it's failing now because I probably don't have access to update the issue. So in this, the condition still is user can update the issue. And that's probably failing in my test right now. As you can see also this is false. So that's the reason why it didn't update the issue. So it didn't run the command and nothing happened. So my test is failing. So I need to make sure that during running the test, the user that is running the test is also able to update the issue. And it's because this issue is created, it's probably in a project that the user has access to. So we have to look up and see the issue is created in project project. And I'm building the issue somewhere else in a project that the user does not have access to. So now I'm adding here that the issue we are building, so not persisting in database, belongs to this project. And in that case, I'm pretty sure my test will succeed now. So let's move over and run this again. Prey, this succeeds. So now we can also check when we revert our code, run the test again. Now we'll see that the test will fail because it was succeeding previously, but now because it didn't have access, sorry, because it didn't have access to update issues. So now it will fail because the condition is not met. The issue is not persisted. And we are testing if it should work without being persisted. So that fails. Let me see if everything is okay right now. So we have made our chains. Let me revert along. Now we want to submit this to GitLab. So we have GitLab in Git status. We can git add those, git commit. So git commits. Why the commit message? Allow copy data for new issues. It's easy if you also, when you do this, you also the issue again. Copy in the link of the issue. So closes. And we create a commit. So the commit is created. Let's go back to our source tree. One thing I didn't do yet. One command over here to create at the upstream remote. I didn't do yet on this repository. So if you see git remote, okay, yeah, in this case it's already set. But when I would run, when I would run the command over here, git remote. So you can see upstream is being set, the fetch upstream, but not the push upstream because normal GitLab outside contributors don't have push access. So you can push to there. And I have to cheat a little bit. So for my fork was created. So copy. Because I've been speeding up things a bit. So back to my code. So this is what you would usually get. So your username with GitLab CE and upstream is GitLab or GitLab CE. So I will be pushing git, push current branch to origin. Sorry. I want to use git for this. That's usually changed. You don't need to make so sorry about that. Yeah, running Rubikop. That's a hook I've added to my git pre-push to ensure all the files match with our Rubikop guidelines. But CI will also running those for you. So don't need to worry about that. So when you've pushed your code, you can create your merge request. And on the CLI, we create a link to that. Just so you can open that link. So let's go over here. And this creates pre-fills in the merge request title. And I'm going to describe here. This is not possible to use copy made of data when you are using a new issue or merge bit. We specify over here the link of the issue, closes this one. So let's assign it to me right now and remove the solid branch when we create it. You probably also want to check this box if you want. Let me just edit it. Sorry, it was a bit too quick here. So this checkbox is convenient for the merge request coaches when they have small changes they want to do to your fork. With this checkbox, the coaches can submit changes to your fork to speed up the process of getting things merged. And then this is your risk request. It's created against GitLab or GitLab CE. It closed the issue. So it's detected when you specify it like this. It's detected that when the merge request is merged, it will close this issue. Over here are a few acceptance criteria. So the change log entry and that's something we really want to encourage people to do and just visit the link here. It's to spell like what's the changes which merge request was and who you are. So for this, we have a convenient command and it should be over here. Bin change log. And you can run that locally. So let's do that. Bin change log. That does work. You have to provide a title. Let me just copy the title over. Copy. Better put it in MRs. Better put it between quotes. And then I'll ask you what the category is. I consider this a feature change. So even this is not working. I again have something wrong with my terminal at this point. Change log. And created my change log entry over here. But it doesn't specify a merge request. So you want to add the merge request link there also. So copy the file. Edit it. Merge request. You need to copy that from the merge request we created. And basically you probably want to also fill in your name here. What I usually do then at this point is hit this. This new change log. Hit edit. Hit commit with amend. So it observes previous commit and adds this change to it. You can preview the commit message. Go back here. And then you want to force push. Hit push. That's what's happening. It was pushed. That's where the page changes here. So we have the change over here. We have a change log entry and we have the test. Yeah, my edit is but don't worry about it right now. So for these changes now we have pipelines running. We can stop the old pipeline because you only need the latest one. And it will run all the tests for you. So you can see later on if those tests did fail. So I guess we can complete this one. Documentation. Like I said, we have a session about documentation data on. You might want to check if there's documentation about copy metadata command. So let's go to doc and just search for copy metadata. Use your quick actions. It doesn't really say if it's enabled or not enabled for new or new messages. So there's no need to change the documentation at this point. So we can check this one. We already added a test. So that's good. Code review guidelines. I encourage you to scan through them to see if you do fine. But with these changes, it's okay. Most requests the same style guidelines are enforced by Rubikop if you're talking about the real part. So CI will complain about those and we didn't make database changes. So this is good. So basically you have a finished merge request at this point and you just have to find someone to review this. Now David, I'm not sure how we are encouraging people to find the merge request coach. Do we have that documented somewhere? Sorry, I was just trying to unmute myself. So first of all we've got a session tomorrow on introducing merge requests. We do have we do have a place with direct people too. It's the when they're trying to get in in touch with the merge request coach. So let me see. It's about gitlab.com jobs minus families slash merge slash request coach. So what I would recommend is if you guys have looked at the kickoff session, we've talked about them and we've got those URLs in the links. I've just pasted it through Slack to tone to you. So you can exactly that's the page. So that tells you what the merge request coach is. What they do and then if you go to the team page of gitlab, then we generally ask you to search for merge requests coaches and essentially you can get to see who they are and you can ping them by person. Yeah, essentially you can just search for merge request coach and then you can ping any of them on the issue. Correct. So Remy would be one of them. Correct. And then if you click on the names of each one of them then you'll see their gitlab handle. If you click on the gitlab icon then you'll see their gitlab handle and you can add that their handle on the on the merge request that will ping them essentially. It would be really convenient if you have a drop down over here for the merge request. Absolutely. I'll file a merge request for that. That would be really convenient for a contribute just to find one. Excellent. Yeah. But basically that's it for my point. I'll stop sharing now and I'll open to any questions at this point. I'm just within the hour. I didn't expect it to take this long but it was a bit of iteration on finding the right way to write the test. So that's good I guess. Cool. Yeah. Absolutely. I'll have one quick question myself. Let me just check if there's any right now on Keter. Is there anyone here in the session who has questions for tone? Okay. So I think as a wrap up I mean there was quite a lot of content and to me it was really easy to see. I've learned actually myself quite a lot in seeing what you are doing. But could you perhaps give us a summary of the steps in doing this whole workflow starting from installing the GDK until you have submitted the merge request? Yeah. That's a good point. So basically for GDK instructions are in the readme how to set up GDK. Basically it's just run GDK install. That's the short version of it. After you have Jodi GDK installed you can run it with GDK run and when that is launched you can browse your GitLab on your local host on port 3000. From that point your GDK is running and you have GitLab running on your local machine. Then you want to start hacking an issue and yeah probably the hardest part about this is finding the right piece of code where you want to contribute. For the issues that are marked with the label accepting merge requests those are most of the time pretty well defined how you can contribute to those. So what are changes it should be? So normally the people who have labeled it has made sure that it's easy to find them. If not please ping them it's no problem to ask for questions on that point. So then you just start writing codes making the changes in where you want to. You probably also want to write tests on that especially for backend code that's pretty convenient to do that. You commit the changes, push them to your fork and create a merge request and from that point on it's let's hope some of the merge request coaches stick over to help you further with it. As like David said in the beginning of the session don't hesitate to ask early for merge request coaches to help you out. If you're stuck with something or you're not sure about the direction you want to go with some change please ping someone and we'll happy to help you out on that. Excellent. So I think unless there are any more questions we can wrap you up here and have it nicely fitted to nearly one hour. So again thanks a lot Tone. That was really really good. I'll be uploading the recording to YouTube and share the link with you guys on the YouTube page for the Hackathon and with that just a reminder that we've got the next session in a few hours time. That's going to be sorry. So that's going to be documentation with Mike Lewis and yeah so looking forward to that and looking forward to seeing you there. Thanks a lot everyone and have a nice Hackathon. Bye.