Transcript
I'm a Developer Advocate here at GitLab, and in today's video, we want to look into Cloud Code and GitLab, specifically context with the GitLab MCP server. In the previous video, which I will link in the description, we looked into the Tanuki IoT platform already and the Arduino IoT collector crashing. There is a specific issue open for that, which we will look into in the next steps. Now we want to connect that into Cloud Code, and by default, Cloud Code might not know about this, but there is one way to bring more agentic context into Cloud Code, and this is MCP, so the Model Context Protocol. GitLab provides a GitLab MCP server for that purpose, and there's also documentation available to make that happen with Cloud Code directly. So this specific command for Cloud to add a GitLab MCP server. I will show you that in the terminal right now, I've prepared it already, so we want to work against GitLab.com, and we can run that configuration. Now we know it has been added, and then let's start Cloud again, and type in slash MCP to manage that server. GitLab is disabled. Let's enable that, and it also needs authentication. Let's go back, authenticate. It will open a browser window. Let's authorize that, close the browser window, go back into Cloud Code. Authentication is successful. Now that this works, we can immediately put it to test. Remember, we are working or looking at issue number four, so quick check here, issue number four, and in Cloud Code, I can say, I need help with fixing issue four. Please help. And we can see that it's building up a strategy here. It will attempt, or it reads the Git configuration and invokes a tool call. So we can see it uses the GitLab MCP server here and the git underscore issue tool call in order to get an insight of what's going on. So it knows immediately the issue is about the Arduino IoT collector. It crashes with an uncalled exception when the Arduino port isn't found. It immediately read that from the GitLab instance, can either be gitlab.com, self-managed, dedicated. It's available everywhere, and we can see we get to fixing much faster here. The problem is clear, and it wants us, or it starts immediately with a fix. First, it catches the exception here. So a try and catch block is introduced. It now goes ahead and actually wants to create a new Git branch. Yes, please do that. And it wants to create a merge request. The first thing we need to do is to git push and set the upstream origin, which happens with the dash U here. So the local branch is tracking the remote branch and pushes that. Now we could go ahead and click on the URL, which is a little unreadable here in blue, but we also have the GitLab MCP server configured, which has to create merge request tool, which we can see here, and it can use that. So let's prove that. I'm authenticated against the GitLab server. So the merge request has been created. It's linked to issue number four. Here's a summary for the root cause. It implemented a fix, and we can open the merge request here. And we can see there's a summary, a test plan. It was generated with cloud code. And the good thing is, again, GitLab workflow kicks in. The CI-CD pipelines are running, so we can follow the progress along here to verify that the source code works. We can also see that an approval is required here from a code review perspective. And last but not least, we see GitLab 2.18 platform with the code review flow automatically triggering on a merge request. So any change that's being made is, again, reviewed against the, for example, the development style guide for C++ and any specific other requirements necessary for code reviews. We will also see in a little bit that there is, well, not in a little bit, we can see actually that it kicked off GitLab advanced test and also the advanced test scanner for C++. So we can make sure that the code is not introducing any security vulnerabilities or regressions or whatnot. And from there, let's peek into our sessions. We can either go here or on the right-hand side, we have the GitLab 2 sessions that are running. And we can see that it's reason, or that the agents are reasoning in the background, providing a summary. And as I've shown this, the review completed, the try and catch block properly handles Arduino sensor initialization failures. Error logging is correct. And it also uses, for example, smart pointers with STD unique pointer, which is a requirement in the code review instructions. And that's fine. And we can also see that when advanced test finishes, that everything works out. If I cannot wait, pressing Command R sometimes also is helpful, but doesn't speed up the CICD pipelines. But yeah, so we can see this is a fix for the initial problem. And we can then move further and loop in more custom agents and flows from the GitLab 2 agent platform. But essentially this video just showed the pipelines are passing. We can approve the changes. And then I could click on merge and have the same nice integration. What I can also do before I close off here, we have to merge request now. Go back to Claude and say, is the merge request running okay? Or something similar to avoid the context switch. Now it uses a different tool to get the merge request pipelines. So essentially fetching the state. Merge is green and ready to merge. So I wouldn't order, it's not necessary for me to do the context switch from the terminal directly into the GitLab UI. I could have just stayed here in the terminal, create the merge request and then check in on the merge request status while I'm already working on something else. So this is a great integration showing the GitLab MCP server together with Claude code, avoiding context switches, get the best of both tools, both worlds. And yeah, I hope you've learned something new today and let us know how things are going. Yeah, thanks for watching and see you next time.
