 Hello, and welcome to Cloud Native TV. This is LGTM. My name is David McKay. You may know me as Rockhold. I am the host of LGTM, a show on Cloud Native TV that is here to show you how you can contribute to the Cloud Native project. Today, I will be joined by Julius Volts from the Prometheus Project, and we will be showing you how to get involved. But before we get started, there's just a little bit of housekeeping. This is a Cloud Native event, and as such, we are bound by the Code of Conduct that the Cloud Native Foundation has enforced. Please be nice to each other and don't post anything in the chat that is in violation of that Code of Conduct. Now joining me today is Julius. Hey, Julius, how are you doing? Hi there. Good. How are you doing? I'm doing very well. Thank you. I'm very excited to the first-ever LGTM. I know it's awesome, isn't it? Can you just do us a favor, and for anyone that is not familiar with you, introduce yourself, tell us what you're working on, and then we'll kind of talk about Prometheus. Yeah, sure. I co-founded Prometheus back in 2012, and have been with the project in one form or another since then, so coming up to the 10-year mark soon. Right now, I've been freelancing around it for the last couple of years, and since the beginning of last year, I've continued that as a one-person company called Promlabs. So helping people use Prometheus, get the most out of it, trainings, consulting, and also building a couple of commercial offerings around it. But Promlabs is completely separate from the Prometheus project. Just want to make that clear. The Prometheus project belongs to the Cloud Native Computing Foundation and has an open governance with people from many companies being on that voting team. Awesome. Thank you. And do you want to just give us again, if anyone isn't familiar, just a quick overview of what Prometheus is? Sure. So Prometheus is a time series-based monitoring system that is especially well suited for monitoring Cloud Native workloads, but also works for other types of workloads. Basically, you run it as a server, you configure it to pull metrics from different sources that you care about. Those could be services, could be devices and expose metrics through some intermediary agent. It then stores all those numeric metrics as time series, and then it gives you a query language called Promql that you can use for alerting, dashboarding, ad hoc diagnostics, basically to dig around in your system state and figure out what's wrong. And also, potentially wake up people at night if something is broken. I'm not a big fan of being walking up at night, but yeah. Yeah, you need teams across multiple time zones, obviously. So, Prometheus was the second project to graduate at the CNC. Is that correct? I think it was. Yeah, I think so. So, I think we were the second ones to join after Kubernetes. We were in the early founding stage in 2016. We joined as the second project. Yeah. And I think there's probably not anyone in the audience or even just in the world that is running Kubernetes that probably doesn't have a Prometheus run in there somewhere. I think we're almost at a state of ubiquity there. And I'm very excited for this little tour of the code and contribution pipeline today. So, Julius, if you could please just kind of get your screen set up and I'll cover a little bit more housekeeping before we move on. Sure. If you have any questions, audience, you can drop them into the Twitch chat. We do have an eye on it. We will do our best to try and answer the questions as we go. So, anything on Prometheus and contributing to Prometheus would be ideal. And, of course, if you're not following the CNCF Twitch yet, now's the time. Click that button, follow. We have so much more many awesome shows coming up soon. All right, Julius, are you ready? I am so ready. All right, your screen is now visible to the audience. We are on the side. You can get started. So, I believe we're going to start with... Oh, it looks like you've got the homepage up. Yeah, is it readable enough? I'm going to do that a couple of clicks tonight if you don't mind, Julie. Okay, I'll zoom a bit. Yeah, that's the problem when sharing the entire screen. It was kind of the easiest for me here with multiple windows in the end and so on that I want to show. Hopefully, this will be somewhat in the readable side. I would go one more, just one more. Okay, that's perfect. Always a trade-off. Okay, yeah. Just wanted to kind of start out on the project homepage, Prometheus.io. So, Prometheus is a quite large project by now. It consists of multiple components. It has an open governance. The community page here explains kind of how... Different avenues of how you would engage with the community on different chat channels. There's an unofficial community-maintained Slack channel as well, this email lists. And we have both of that for kind of the user side which is this whole thing. And the contributor side, right? Which is in the contributing section. Just so that kind of the usage issues get a bit separated from development issues. We also host openly and recorded developer summits once in a while where we decide how to steer the project and what things to do next. You have a code of conduct as well, which is the same as the CNCF code of conduct. Legal umbrella, as I already mentioned, part of the Cloud Native Computing Foundation. And how we actually make decisions in Prometheus is... Oh yeah, at the very top is kind of explained in our governance document. And you can see the current team members here. So, they do come from different companies. The only special status that I have remaining is that I'm a co-founder, but I don't control anything besides having a vote on that team. Amazing team doing great work on things. So, if we go to the actual code base on the Prometheus GitHub organization, you already see a bunch of different repositories. It says 39 here. Can you speak German again, please? Oh yeah, thank you. Oh, this is a, yeah, this is a precise thing that I have to do the zoom, right? So, Prometheus is a larger ecosystem with a bunch of integrations. And for example, the Prometheus server and the alert manager are different components that would live in different repositories. But then you also have all these agents that can expose metrics for different types of systems, which we call exporters. And they're all, you know, we have a couple of official ones that have their repos here. We have instrumentation client libraries like client Java, client Golang and so on. But I think, you know, what we wanna focus on today would be the Prometheus slash Prometheus repository, which that houses all of the main Prometheus server code. Can you go one more, sorry to be a pain. One more, yeah, sure, sure, sure. So this houses all the main Prometheus server code that, you know, the server that actually collects your metrics, runs promql and does all the main magic that Prometheus likes to do. Any questions so far, or I will just go on. I can just go on. No questions, no questions yet. I wonder if there's Prometheus, Prometheus, a mono repository, does this build a single binary? Like, what is the structure of this? I mean, we do have other repositories for the different other components, for the other binaries. So mainly this has only the Prometheus server binary. There's one exception to this, which is it has two binaries in the CMD directory here. One is the Prometheus server and the other one is little CLI tool called promql, which helps you do things like validate configuration files and things like that, you know, some interactive things, but also things you can use during a CI check before you apply a Prometheus config file, for example, to see if it is correct. But, you know, other than that, it's a mono repo, yeah. Okay, so... Oh, it's not a mono repo, it's for the Prometheus server, mainly. Yeah, so that's like, you know, if we try and think about if I run a Prometheus then and I want to make a change to it, that would involve the collector, the time series database itself, and promql, those are all part of the server, is that right? Yeah, I can actually show you. Oh yeah, here it is. I wrote a document back in, I think it was like 2019 or so by now. It's in Prometheus documentation, internal architecture.md, which I wrote with the aim for new contributors to find to understand the actual structure, the layout of this repository. So all these boxes you see in here, they basically represent what's happening inside the Prometheus server. And a lot of these boxes also kind of mirror the directories we have in the code base in the GitHub repo. It's slightly out of date now, since it's a couple of years old, but most of these structure is still the same. So, you know, a couple of storage bits have changed and so on, but roughly how the different pieces fit together is still very similar. I then, you know, document all those different pieces you would see in the diagram above with links to the code. So it starts with the main function, which is really the central entry point where the server starts up, loads its configuration file, looks at its command line flags, constructs all those other boxes you see in the diagram above and kind of wires them all together in the way that you configure it to. All right, I think the top tip one then from our episode within the first 10 minutes is that anyone looking to contribute to Prometheus should be looking at the internal architecture document under the documentation. Yeah, this really should give you a pretty good idea of, you know, how all the different things are tied together into different concepts, yeah. And then, you know, it has all these links to the actual code where, for example, here is hash by its level set and it's final scrap URL and it takes you there and it shows you where that is happening. Now, you know, not all of these links will be fully up to date anymore, but they should give you this idea. I should really find some time to update this document sometime would be really cool. That would also be a good first contribution for anyone watching, you know, go check out those links and make sure they're still pointing to the right place. I mean, basically you have to go through the entire code base to read it. Just for kind of, or at least, yeah, repoint, like see if things still fit together in the same way and then link to the most recent code version with an absolute link. You know, all these links here, they do include the Prometheus version and not the latest main head. Yeah, so this is a good starting point, I think, for people who want to get an idea of how the code in this repository is structured. Other than that, like, let's say you have a rough idea of what all this looks like and where you want to make a change, there is a contributing.md in all of our repositories, so also in this one, but also in the other ones, that goes a bit further into the considerations you would want to make before a contribution and during a contribution and how you would actually build the contribution. So, yeah, this is just a link to further down to here. So basically, the general rule, I guess, as with a most open source project, if you just want to fix a typo or something small, very uncontroversial, just send a pull request, it's not a problem, but if once you want to do something where some discussion is warranted first and it's not clear that this is something that everyone is okay with or agrees on that this is a right design decision or so, then it makes more sense to have a small discussion on the mailing list first. So, just kind of use your best judgment there. If it's a couple of lines of code change, just send a pull request, maybe, but you don't want to spend a day working on a huge change only for then someone to say, like, this really doesn't fit in with the vision or so on. Yeah, I think that's so important. It can be easy to be really focused on your own individual use case and context and something seems like it's really obvious. And, oh, of course I should do this, but you got to think wider and broader. I mean, Prometheus is a project being used by tens of thousands, if not hundreds of thousands of teams and developers. All these new features have to be really considered before they're merged directly into the core product. They have to be considered the kind of need to fit in. They shouldn't have weird interactions with other features that you, as the one user needing that, aren't in that moment aware of. They need to be maintained and documented over time. At the same time, we have become also consciously decided to reconsider a lot of times in the past where we have said no to reevaluate some of those positions and be more open towards potentially adding some new PromQL features and other service discovery implementations where we had been more on the conservative side before. So I think generally we are pretty open now, but of course, you can't put everything. You can't make everyone happy. That's always impossible. Cool, so then let's see what else do we have here. We have a couple of guides around our coding style in general. All of our commits need to have this kind of signed off byline that you may be familiar with. Need to have a line that has your name and email address. Otherwise, a CI check will also fail. This is just for legal reasons to kind of secure ourselves against any legal trouble to, for you to state, I have the rights to contribute this code and it can be hosted in this repo under the Apache 2 license and so on. Great, and so now to actually contribute, you probably want to first check out the code and then be able to build it and run the tests. You need go for, so basically recent version of go for building the backend and then NPM and yarn stuff, the Node.js stuff for the front end to be able to build the front end as well. So yeah, that has become a requirement. I want to show one kind of cool thing. You can actually use gitpod.io to spin up a pre-built dev environment. So this URL here, I actually will copy it so you can see it more clearly up here. It's just gitpod.io and then you can add any repository URL there. In this case, github.com slash Prometheus Prometheus and github will, gitpod in this case will check out that repository and then give you an in browser VS code style experience. And if you do have a .gitpod.yaml like a config in your repo, it will not only check it out, but it will also execute some pre-built steps. Like it will build the Prometheus server, it will start it up for you and so on. So I'll just let that load. I do not have the setup to actually, you know, like commit from here and submit back to github, but that's just due to the way that I didn't want to, for some reason I couldn't give it the right github permissions yet, but that's more of a personal decision. Like normally you could theoretically completely use gitpod as an in browser way to develop Prometheus and to build it. So I use it a lot for, like when I do get a pull request, you can also just say gitpod.io hash and then the URL of the pull request and it checks out that pull request starts it up and I can like immediately play around with changes to the pull request in this editor here and then start it up again and then give feedback on the pull request saying like, hey, I tried out this one thing. So I don't have to locally check out someone else's code review branch. So pretty cool. I think one of my favorite things we're using gitpod in this fashion as well is like they're build servers or like 32 cores and 64 gig of RAM or something silly like that. So you're not using your own CPU in memory to build fairly large projects and it's much quicker in this environment. So yeah, big plus on the gitpod here. The full vision of gitpod is ultimately you move all the development into this cloud editor and you don't have any local fans running anymore, right? Maybe I will get there as well. So because you do have a terminal here, I could stop this Prometheus editor and then you can do all your git commands here and look at what's going on. You can create a new branch, foo and then you could push that and so on. But then if I do that, I would have to grant it more permissions in my GitHub account. So that's just something you need to be aware of. So for today, I just wanted to point this out as an awesome way to kind of get onboarded without having to install Go and Node.js and Yarn and so on locally. If you have no problem setting up that stuff locally, that's also fine. I will now do the next steps locally just because then I can actually commit the stuff and so on. You can also do it to Gitpod. Maybe I should point out two little build things here. Yeah, I haven't even mentioned to read me yet, which of course also exists, which goes a bit into the architecture as well, just zooming out a bit for overview. The different, how you build source. Yeah, I just wanted to see what's actually on the page. So this also gives a bit of a, how to use this repo instructions. Plus, if you do search for read me in the entire repo here, you'll see that many of these sub-direct rease will contain read me by themselves. For example, service discovery has read me as well, which explains the design of the service discovery components and what should go into this repo and how they should be. So if you want to add a new one, what interface do you have to follow to make that happen and so on? So you can find a lot of more detailed information in those sub-read me's. What is the magic shortcut to open that fail search as well? Oh, that's a T. T, nice. Works on GitLab as well. Oh, sweet. There you go. Super helpful. So yeah, wow. I didn't even know we had that many read me's. That's pretty cool. So yeah, as for the structure of this repository here, like CMD, as we've already seen, contains the two actual command line tools, the server and another little helper tool. And then we do have just a bunch of directories kind of mirroring some of the larger components of Prometheus, service discovery, alert notification sender, the actual promql engine is in the promql directory, rule management, scraping, like this is the thing that really, the code part that really fetches metrics from targets and then sends them to the storage and the storage list here and a bunch of more things, right? So yeah, that is this repo. Let's maybe first have a look at how we build things and how we get started in general. So I'll switch over here, do a lot of zoom steps. Hopefully this will be sufficient. Yeah, I can read that, I think. Yeah, that looks okay. Clone this repository that we have just seen. I think there's also instructions here, right? You can always just go to this button, copy this URL here. I gotta say, I installed the GitHub CLI a few months back and it has just been fantastic. I love the ability just to do like GH repo fork and it creates a fork and sets the upstream origin and stuff like that. I wonder if I'll have that installed. I don't, okay. That's cool though. So I'm just doing it the old fashioned way, good clone. So checking out this repository too, as you will see an LGTM directory here, especially for the show. And I'll go into there. We have all the files. Oh yeah, so building, like theoretically the Go part, you could just run by, you could just build it by saying like Go build, CMD Prometheus, the package. So that works, but we have also a make file, which has a couple more steps. Like it will make sure that it will actually also build the latest UI assets for you and it will inject, like it will compile them into the static Go binary that we're building and it will also inject, it will set some linker options. It will actually inject some information about the version into the binary and so on. So for just some local quick testing, it's totally fine to just do like Go build, CMD Prometheus or go run.cmdprometheus. But if you wanna build the full final binary with everything up to date and include it, you will probably wanna do make build. I guess it may take a little bit of time. Doesn't it? Yeah, it does take a little bit of time, but not too long, like maybe, I don't know, maybe a minute. It builds Prometheus and Chrome tool. Like at the moment, it's building that React app, creating a production build for that. It writes those assets into a directory where it then kind of encapsulates them in a Go file that is then compiled into the actual Prometheus server binary. So I'll just let that run in one tab. And in the other tab, we can talk about testing. So the other thing is you can run tests. Can you run more quickly, please? Yep, like this, one more? Yeah, I think that's okay. Okay, so make tests, after you make a change, right? You will kind of wanna make sure that all the tests still pass. And optimally, if you make a significant change, you'll probably also wanna add a test for it or adapt an existing test to make things pass again. So before actually opening a pull request, it's a good practice to run the tests and make sure they all still pass. So I will just let these run in parallel and then switch back to the other tab here. Can we take a look at the issue list now? What was build and test? At which one? The issues list. Oh, yeah, that's a good idea. So we'll just let those two run. Let's go to the issues list. So like going back to the repo, if you go to the issues tab, you will see a bunch of issues. There, we have a number of labels with different meanings. So if we go to the labels here, we try to tag issues by the actual component of the server they touch. We have priority labels. We have kind of the kind of change that someone is asking, like someone finding a feature request versus reporting a bug, for example. And we have two that could be interesting here. One is help wanted. I'm gonna click on that. And another one is, wait, low, huh, oh wait. I may be on the second page. We have two pages here. That's why I didn't find it. Low hanging fruit. And we also have not as easy as it looks label which has come in handy because often issues do come in where something seems like a trivial change initially. And then we're like, oh, well, this actually touches these 10 things over here and would completely invalidate some invariants. And I don't know. Someone really has to think about this much more before we just make this change. And so maybe as a first time issue, those wouldn't be the. Yeah, avoid those. Good ones could be the low hanging fruit ones in general. It's just small changes and help wanted. And I can't tell you like the 100% difference between those two labels at the moment. You know, they're relatively similar. Sometimes you do see them used together. But I guess help wanted is especially an invitation to the outside world where, for example, open BSD, right? Like we don't have open BSD. So it's really cool if someone has open BSD and they can test on there, then especially we would appreciate their help. This kind of stuff, right? So both of these can be great. For the purposes of today to actually find an issue that we can, you know, look at, understand and just send a pull request for within the scope of this show, I've actually created one, which is this one here for the React user interface. Oh, someone already reacted. That was too mean. Okay, so this is a very, you know, it's going to be a trivial change, but the idea here is just to go through the motions of what it takes to, you know, make a change, make the tests pass, check out the branch, push it to GitHub, make a pull request and see how that goes, right? So recently we introduced a completely new PromQL editor in Prometheus. We can actually show this, I think. Yeah, I guess I can go to demo.promlabs.com to show this and turn off this experimental PromQL editor. So this is a running Prometheus server, which I also will actually zoom into a bunch like this, maybe, and yeah, so, you know, it allows you to input PromQL expressions like rate, oops, I know it's so slow, off some metric and now I'm already wondering like what are my metric names and it's not really auto completing and it's not syntax highlighting either. It's not also not showing me that I'm doing anything wrong. So we added a new experimental editor that's based on CodeMirror with a completely new like auto completion, syntax highlighting and inline linting framework that was a collab between Augustin Husson from Amadeus and myself. And this one, you know, just really, really helps you a lot because, you know, it has all these, it has way more auto completion, it has syntax highlighting, it has things, features like this one here where you can build your query pretty quickly shows you help and types and so on for the different metrics you're working with. So this is a new editor which you can turn on or off, right? That's the old one, this is the new one. Instance is something, something. So you can see definitely it will make your life less painful when working with PromQL. We didn't make it the default here immediately when we added it because you never know you release it to a bunch of users and they might find a lot of problems with it. But so far the situation has seemed okay and it does seem, you know, it does add a significant advantage in the PromQL editing process over the old one. So it would be great to actually make it the default. So the goal of the issue would be to default this checkbox here to be true. And eventually you can also see there might be an opportunity here to hide all these top level config options under a config menu somewhere because they're kind of getting out of hand and if your window becomes a bit narrower then they don't even fit on one line anymore. But that's for a different day. Okay, so back to this issue here. Let's actually look at what our code is doing here. So it's still running some tests. The build has of course completed already. So that's good. Like now we could start the Prometheus server. By default it will try to load its config file from config.file equals Prometheus.yaml which would be fine, but you could point it somewhere else as well. I guess we won't really talk about like how to configure Prometheus itself in this talk more about contribution, right? Yeah, yeah. So I'll just kind of skip that. But now, yeah, we could start it and you could try it out and see, you know if it behaves as you expect in here, I don't have a Prometheus.yaml yet. I would have to copy it from documentation, examples. Prometheus.yaml put it here. And then by default it would pick it up and run and so on. Okay, cool. So how these go tests? I don't know if we're gonna start with something. I will terminate them for now because yeah, for now let's actually just start Visual Studio Code in here which I recommend as an editor but there's of course other people who prefer others. Let me see. Ooh, now the question is can I actually zoom in the left-hand bar as well? I probably don't need to, you know. Yeah, you can either set the font size larger. I don't think we need to see the sidebar or you can just command plus everything else. Hide the sidebar. So I happen to know where this code lives. If you don't know where the code lives that says use experimental editor, we could also go and find it, right? Like we can, oh, not search or replace. I could just use, just search for that. And now I find it in panelist.tsx. And I also find it in a test file here and here's where I would really wanna zoom in. Zoom, zoom, zoom. Is this maybe one more, right? Yeah, one more again, please. One more. Okay. Cool, so I'll keep this test file open and then also the actual implementation file. Close the sidebar. Maybe even zoom in one more step here. Okay, so now we're deep in the React code. And I guess the whole React web app is a bit too much to explain right now. But you know, even not knowing a lot of React, you could maybe find out where the default is set. So there's a checkbox here and when it's changed, it's calling this set use experimental editor value to the checked value of the checkbox, right? And like where does that initial default actually come from is kind of the interesting bit here. So default check comes from use experimental editor. So we'll search for like where that actually, the first occurrence of that is in that React component here. So the panel list, we are using a React hook. Again, probably can't really go too much into React details now, but we're kind of locating a place in the browser's local storage, which is where this is stored this Boolean bit under the key use new editor. And the second parameter here is a default value. So by default, currently, this is set to false. So this is basically now when the React app doesn't find that local storage key yet, it will create it and set it to a false value initially. So we wanna change that default to be true. So I'm just gonna change this here to true, hopefully easy enough. And we could now run the full tests, but we can also just run the React app tests. Oh, nice. So make React app tests runs only the tests for the actual front end code. And let's see if they actually pass. But they do not. So why do they not? Because we actually do have a test in panelist test.tsx that checks what the default is for that experimental editor checkbox. So if we go to that test file, which I've conveniently already opened here, it's kind of duplicating that information from the actual code file. But yeah, it just kind of checks that these checkboxes are present with the expected default value and the expected default is still false. So I will just set that to true here. And the test runner automatically detects this through a file watcher and just reruns the necessary tests. And hopefully everything will actually pass. Yep, so now everything has passed. I can terminate this interactive test runner by pressing Q. And now I would probably just like build the entire thing and just kind of make sure that everything works together. This is one thing I can do. Like this will compile the React app. It will build it into the Go app and build the Go app and so on, but I could also, I'll open yet another tab. I could also just have my main premises have already running and then only test UI changes by going to web UI React app and just saying yarn start and what that will do is it will start up the React UI itself only and any API calls to the backend Prometheus server will be routed to this Prometheus server on port 1990 running in this different terminal tab here. So that's kind of a little config option we have in our package JSON where you can just leave the actual binary with its backend API running if you only wanna do front end changes you just do the yarn start. And the nice thing about that is that, that will then automatically in a bit open the UI in the browser here running against that binary server that's running can take a second on the first load because this is a completely new repo. And the nice thing about this is that any change you make to the code will immediately cause the React app to reload that part of the page. So you can do like really interactive development whereas if you had to do a full make build on every UI change to iterate would then be really slow. And so this allows you to iterate really quickly. Come on, load. I think my computer is a bit overwhelmed with like streaming and building and testing and all at the same time here. This is why Git plan is so cool, right? Yeah, exactly, exactly. So I should really look into those permissions. I'm sure it'll just take a few more seconds. I like that, you know, you're kind of showing that we can build the previous server on this one and we can build the React application on this one or we can build them all together as well as a couple of make fail targets for just running the React tests. I'm assuming there's one for just running the previous test. So, you know, you don't need to do the all in one solution once you're a bit more familiar with which changes and what component you're working on, which is great. Yep, I'm a bit surprised by how long it's taking, but I think it's just because it's, you know, doing too many things. Oh, I will, I will just, you know, oh, it should be done in a second though. I think it's just mainly this main build here, which is also doing things in parallel and so on. Hugging, hugging everything. And so, you know, my age top, wow, okay. Yeah. Those are four cores fully utilized. Perfect. Okay. So, da, da, da, da, da, da, da, da. Come on, you can do it. The little build that could, it's like almost there. Yeah, I'm sure it won't be much longer. Oh, there we go. We got it here. The guy has actually loaded, yeah. So, you know, I could actually, you know, if I couldn't now like make changes and there would just appear here without me having to even reload the browser windows. So that gives you a nice way to do like iterative UI development. But in our case, you know, we, I'm already pretty confident that this was a good change. So I'm just gonna, I mean, it already built the Prometheus server. So I'm just gonna terminate this for now and actually just start up the new Prometheus binary and see in an incognito browser without any local storage if it's doing the right thing, right? So I could just go to localhost 1990 and see, yep, that default is set and it has a new editor. Awesome. Okay, cool. So now I see my diff here. It looks reasonable. I have, you know, a little test change and actual code change. Now I wanna create a branch for this. So, you know, I could create a new git branch and call it, let's call it change new editor default or so. Now I should probably have mentioned that you probably will not, like as a first time contributor, you will not have right access to the actual Prometheus repository. So the first step you will want to likely make is to fork it, right? You will go to the actual repository and you click the fork button here which creates a private fork under your username of that whole repository and then you would clone that locally instead of this one and then you would push your pull request branch to your fork and then from your fork you would create a pull request. In my case, I happen to have right access to this. So I typically push my review branches directly to the Prometheus, to this repository here and not to a private fork. Okay, so I'm creating my branch and now I'll create a commit and in this case, I want to just commit all changes. I don't have any other changes laying around that I wouldn't want to commit. So I'll just do the dash A here and add in this case, I think just a single line here, you know, make the new Prometheus editor default. If you do look at, I think is it commits some previous commit messages, some are pretty free form, others have like a little prefix here. So I may, you know, we don't have strict rules around this in Prometheus around kind of like semantic commit naming, but if you fix something it can be nice to kind of start out with fix or, you know, fix colon or so. In this case, might be nice to say react UI, make the new Prometheus editor the default. And then also we will want to make GitHub auto close the issue that we are fixing here, which we can achieve by mentioning in the pull request body. So we're heading back to the issues in the repository and finding this issue URL. And we're just gonna mention it in the actual commit message. And you see, I have my whole Git flow locally with some hooks set up in a way that it already automatically adds the signed off byline. You can find ways on the internet how to do that or you can just manually write it. But it's super handy if you just have like a little commit helper tool that helps you do that. Cool, so it's committed. I can see it in my Git history now here. I can push it. So this push normally would go to your private fork. In this case, I'm saying it directly to Prometheus Prometheus. And then if I reload this page here soon, I should see a little banner at the top even telling me like, hey, you just recently pushed some changes. Could also, oh wait, I have to go here, right? There you go. Yep, had recent pushes less than a minute ago. You could also go somewhere and do it manually, but normally this is the way I do it. I just say like, okay, compare my recent changes that I pushed, I wanna create a pull request. Now, if you are, well, there's like a little commented out template bit in here that just tells you a couple of things that you shouldn't forget before submitting a pull request, right? Like check that there are tests and that they pass and so on and so on. In my case, I'm pretty confident. And you don't need to remove this here because it's commented out. So it will just look like this in the end. Okay, so I'll just create the pull request here and let's see if anyone is actually online to review it. I could now assign a reviewer and my favorite reviewer here could be in this case, Julian, who actually suggested that this could be a good issue for this show. I have no idea if he's actually currently watching, but so he may or may not like this change now. And if he likes it, he would, you know, actually click on some buttons below and say like, you know, I approve this or he would just send a thumbs up. But in any case, no matter whether he approves it or just sends a thumbs up or something, we want these tests to pass and go green before we actually merge it, right? And in general, the rule is like, even, oh, look, he approved, thank you so much. Once tested, I agree, wonderful. That is awesome. Good cooperation here. I think we should set like a little warning though, that a disclaimer that not all pull requests will be reviewed within 30 seconds. Yes. I'm also guilty of that. Like apologies to anyone who contributed where I just completely, you know, lost sight of something which happens to me on a regular basis. But such is the thing when you, you know, often you have so many things flying around and yeah, priorities, it's tough. You got a comment from Dan Popson, what a responsive community, Falko, I'm jumping chip. So at least that you're getting a pop on the Prometheus team there, he's on his way. Oh, awesome. Okay, waiting contributions here soon. So can I just ask a couple of questions? I mean, you signed that manually to somebody, but I'm assuming first time contributors aren't really going to have the ability to do that. What is the procedure and protocols for them when they open in your pull request? Excellent question. Yeah, so often I actually, I mean, yeah, if you have kind of the, you know people already know who is responsible for a part of a repo, you may just CC them or select them as a reviewer. We do have a whole maintainers.md file here, which by the way, it is mentioned from the contributing MD, I mentioned initially, which is like if you have it at a suitable maintainer which are listed in the maintainers MD. And so this gives you an idea for the different parts of this whole repository who is most responsible for what kind of the default maintainers. And we have Julian as the main and default maintainer for the rest of the repo that is not explicitly mentioned here. So, but, you know, you can also choose to not mention anyone, but it can help to mention someone because it gives people a more clear sense of responsibility that they should look at something, you know, otherwise, you don't know. So it can sometimes, it's as so often with, you know, in any work situation where you have always more things flying around that you can do it always in the end in practice, you just poke someone a bit more and eventually, you know, they will notice. Okay, so we, yeah, we will probably, you know, it'll take a while for some of these tests to go green shouldn't take super long, but probably, you know, won't be able to merge it right now, probably shortly after the show. Cool, but that is basically the flow. Finally, then, you know, I would click on the button here that would eventually go green and allow me to just say, yep, merge. You cannot do that as a contributor if you don't have right access to this repository. So normally that step would be done by, you know, by a team member of Prometheus who has right access here. This is kind of the positive flow where everything just kind of works itself out. There's an immediate, it looks good to me, coincidentally, the name of the show. But of course, there can be situations where like the usual case for larger changes will be that there, you know, there will be some comments by the reviewer maybe either pointing out a bug or making some suggestions how to make code a clean arm or maintainable or like, have you thought about this? Would this be a better way of doing it? And, you know, feel free to discuss. But yeah, in the end, of course, the people who decide what gets merged, how are the Prometheus team members and the maintainers of the repository? Awesome. We have a couple of comments in the chat as well. From someone I assume is maybe familiar with the project. They've said that there's also a code owner's file to help find and be responsible for a single piece of code. And they also mentioned that the CIs actually provide a preview environment for the UI, which you can also check out as well. Yes. Oh, I should totally mention that. So the code owner's file we introduced very recently, mainly because I wanted to get notified whenever someone sends a pull request that touches the web UI directory. Because before that, I would just often miss these. This is actually a nice way for you to have GitHub notify you when a pull request touches a certain sub directory. So that's actually really cool. Yeah, so going back to our pull request, let's see if that CI check that you mentioned is already finished. Those comments were from ZaraCM. Yeah, so you have one CI check here that's the NetlifyDeploy Preview, which gives you an actual Deploy Preview of the React front end. And we see the correct checkbox set. Haven't zoomed in here. So that works. And the way it's not running, Netlify only hosts static files in this case, which is only the front end. So we kind of have a little magic proxying set rule in the build step in Netlify that points this React front end at a demo Prometheus server we have running from the Prometheus project. So this will actually have some permanently running Prometheus server that it is pointed to and that it's showing the data for. Awesome, thanks. So this helps if you don't pair this with an actual backend change, right? Like otherwise the backend server for this React preview would not match your backend and front end change. Yeah, that makes sense. And I can imagine people may probably work on this in isolation. I think it would probably more likely that you make changes to the front end and isolation from backend changes. Yeah, yep. All right, awesome. That is great. Thank you for walking us through all of that. Is there anything that you want to show or will I pop this back over to our bigger chat window? Yeah, I think I'll actually stop sharing at this point or maybe keep it on in case there's any questions that I can still show anything. Yeah, if anyone has any questions, you've got a few minutes, please get them into the chat and we'll do our best to tackle them. We had a couple of comments throughout that we can cover just now, so let's see. Audacious Farrell says, I was told that Golang builds are fast. Well, they're incremental. They're faster after the first time, but. I think they're relatively fast. It was super fast initially. When we started out with Prometheus, it built in like six seconds or something. And yeah, then we added more and more and more service discovery code and even just adding Kubernetes client libraries in there and things like that really ends up making things larger. And now the binary is 94 megabytes. I remember a time when it was like 16 or so. But in these days and ages, it's nice to have a lot of functionality baked in there. And it's a large project as well, right? It's a large project. It has a lot of functionality. It supports service discovery for a lot of different cloud providers, container schedulers and other mechanisms. And yeah, there's a lot of things. So obviously the React stuff isn't there as well. I'm assuming as Zara CM must be a member of the project somehow because they've also commented in Prometheus builds with 30 plus architectures in 20 minutes. Yeah, yeah, yeah. So we actually do build in the end the releases for all the different architectures and so on. So yeah, I think my computer here with the streaming and everything else going on was a bit overwhelmed. It normally does not take that long, for sure. That's fair. Okay, well, I don't think we're going to get any more questions. So with that, I'll just say thank you again, Julius. It was really great to go through all of that. You know, I think there's a lot of great tips there for anyone who's looking to contribute to the Prometheus project. And of course, if you need any more help, you can reach out to either of us on Twitter. We'll do our best or open an issue on the Prometheus repository and we'll do our best to help you out as well. That is it from us. Feel free to tune. Well, you should definitely tune back. Declare native TV in a few hours and two hours time pop will be hosting spotlight live. It's going to be a great conversation with the Kupcon panel. There's chairs on Kupcon, so looking forward to that. Julius, I will leave you there. Thank you again so much. I will speak to you again soon and to everyone watching. Have a wonderful day. Thanks. Thank you. Looking forward to contributions. Thank you. Bye.