 Thank you, everyone, for tuning into my talk. I believe, coincidentally, this talk might be an answer to David's problem with how to make sure that all 200 projects in KE get switched to not autostarting key jobs. But let's see how it goes. Recently, I became a huge fan of static code analysis, so I decided to talk about static code analysis and about GitLab CI and about what you get when you bring those two things together. Spoiler alert, you get awesomeness. I'm sure everyone here knows what static code analysis is, but let me go quickly through it. It's like a second pair of eyes that checks your code. It's not just unit tests. It's actually some tool looking at your source code, which means you need something that understands C++, and understanding C++ is not the easiest thing in the world. Luckily, we have these things that understand C++ code very well. They are called the C++ compilers. So no surprise that the two major static analyzers that I'm going to mention throughout the talk are both based on the Clang C++ compiler. The two static analyzers that I want to talk about are Clazy and Clang Tidy. You may have heard about Clazy. Clazy is actually a KDE project. It's a static analyzer with a wide range of Qt-specific checks like this one. For instance, if you use a non-static, non-const Q-vector in a range-based for loop, it's perfectly valid C++. It compiles, it works, except it's not ideal because using a non-const Qt container in a range-based for loop might detach the container. This can easily skip a pass through review, especially if instead of Q-vector in, it would just say auto, and if you often mix standard containers where this is perfectly fine with Qt containers, it's easy to miss this. Luckily, Clang Cable give you a warning that this is not okay. You should fix this. It's going to also possibly fix this for you even, but that's not the point of this talk. Another my favorite check I think in Clazy is this one. We have a little Q-object class with an enum and a Q-signal that has the enum as a parameter. This is, again, perfectly fine. It compiles, it works, it's a valid C++, and in a new connect syntax, it will work just fine. But if you use the old Qt-4 connect syntax, this won't work because the argument needs to be fully qualified as Clazy will tell you again. And again, this is something that's easy to miss, especially if you are new to Qt or if you are not using Qt all the time because then you need to remember, oh, now I'm writing Qt, I need to remember to fully qualify my single argument. It's really useful to have a tool that checks this for you. The other static analyzer that I talked about is ClangTidy. ClangTidy is part of the LLVM project, so it's actually developed as part of the Clang compiler. You get it alongside the compiler with other Clang tools. It has a wide range of generic C++ checks. So it can check for bug prone statements like this one, which is perfectly fine. Again, it compiles, it runs, it works, except when you compile it without asserts, suddenly this decrement will not happen anymore because the compiler will remove the whole line because you wanted to remove asserts. So ClangTidy will warn you that this is a bug prone statement, you should fix it. It can also help you with code quality. So I'm sure every single KDE project has something like this somewhere in the code, so a magical constant defined as a macro. ClangTidy will tell you why don't you use constexpr? It's exactly the same as a macro and it's type safe. So static code analysis is super useful. It is very helpful, especially if you can do it as part of a review process, because then the reviewer can actually focus on the big things, the ideas, and on the actual what the code does, rather than having to focus or pay attention to these small things, like not fully qualified argumentative cue signal and similar. So I guess it would be really nice to get this, right, to use this. And the question is why are we not even using this for all our projects? I ran this on the Yaconati code base and I uncovered quite a few bugs or issues that both ClangTidy and Claysie warned me about and I could fix them. The problem is that I ran it once, I think after a very, very long time, and I got like lots of issues and I spent several evenings just fixing them and it was not fun. It would be much better if we were able to sort of do this incrementally, right? Of course, there's not no problem if you want to run it everything, like, you know, sit down before the release, you run static analysis on the whole code base, you fix everything, and then after three months you do it all again, but then it's not really good, so comfortable and we have two links to do that for us. So I thought like maybe we could do this, maybe we could do this for each pull request, right? So this is where the second part of the talk comes in about GitLab CI. Here I want to pause here and say just a big thank you and kudos to the CISA admin team and everyone who was involved in switching over to GitLab. I'm so happy we have that finally. GitLab CI, you may have heard about it, I think it was a Friday it was mentioned on the Friday training about GitLab as well, it's well it's a CI and it's built directly into GitLab. It's basically like our own Jenkins to build KD York except this is actually part of GitLab. What that means is that it can execute the jobs on not just on each comment but also on particular events, like for instance it can execute your CI job or CI pipeline on each pull request and I'm sure you know where I'm heading with this, how can I get this? How can I get my own GitLab CI jobs for my KDE projects? This is another advantage of GitLab CI with the old Jenkins setup. This is all managed by the CISA admin team and basically what we do is every project get the same treatment. All the projects are just compiled, desks are executed and that's it. There is no point where you can customize it at your own settings and whatnot. Luckily in GitLab CI all you need to do to get your project to create a pipeline for your project is you need to create .gitlab.ci with the YAML file in the top level of your Git repository and then you can define your pipelines. How to put it up? Well again our CISA admins are super awesome and they created existing definitions so you just put in these to you include these two YAML files which contain definitions for the pipelines and the jobs in there. So for instance this one a CI before is just some templates and the CI applications linux. This will create a job for a KDE application for you there's also CI frameworks and CI extra here and then this will create a particular job for linux. There's also free BSD and windows so if you just include whatever you need you'll get automatically created jobs right so if your project is not interested in windows or doesn't work on windows you just don't include that file that creates the job and if you want to define your own job that does magic well you just define it in your YAML file and you get it so you as a project developer you can really customize this which I think is really awesome and well as part of that I thought well maybe I could we could get static analysis as part of it as well right actually this all started shortly after the migration ticket lab when Loran Montel went and he added some sort of initial static analyzer set up into all the KDE repositories unfortunately didn't work so I guess first I started removing them from from the repository and I realized well this actually might be super useful let's try to figure out how to do it properly so that we can get proper green pipeline so this was the first attempt nasty I know it's complicated and really you don't want everyone to copy paste this into their KDE lab YAML it's hard to change it requires committing additional files into the repository it was like it was bad so I took some inspiration from the existing include files and just created the job and the pipeline in the in the sysadmin repo oh well it's not there yet but later on that and all you need to do is you just include this file and you add this include into the github ci YAML and then you also create the new job which you do by saying well this is the name of my job and it just extends this template it right now it cannot be auto-created like the for instance applications Linux jobs which you don't need to define any matter they just get automatically created it's because either I'm too bad with the github ci stuff or because I because maybe kind of be done better anyway this is how you get it and magically suddenly what you get is a ci new ci job called static analysis that gets executed on every single every new pull request and again whenever you comment add a new comment to the branch so what exactly does this job do first it builds the entire project uh you have to do it because the static analyzer it needs for the code to compile right and unfortunately it's queued we have a lot of files that are generated as part of the compilation steps so we have the mock files the ui files the debuts editors and whatnot that all this all needs to get generated and so that uh so that it can when it's included for some other c++ file the compiler actually has access to these includes otherwise the the the compiler just says can't compile I will not do any static analysis on this so I did some really crazy stuff to get it to try to get only the generated files without having to compile everything but it failed I was not able to force make or cmake to only do the generation if anyone knows how to do that how to force cmake or make to only generate all the files without that needs to be generated without having to compile everything that would be tremendous I even tried like crazy check create some crazy ideas like uh creating a script that defers to a real compiler at configure time but then does nothing at build time except of creating empty files so it would be much faster uh but then it failed already in akonati because in akonati we have a custom uh utility that needs to be compiled first and then it is fed another an xml file and it generates some more c++ code from that that that gets included here from other places in akonati so uh when I so fake compile this generator it obviously didn't work at the compilation fail anyway and all the static analysis fail anyway so I ended up going with a let's just compile everything uh we had some discussion with Ben about this on the review maybe the solution to this would be to put the static analyzer as a test stage after the build under the regular main build so the linux build so that it can reuse the build directory created in the in the regular build job the next step that uh this this job does is it finds changed c++ files uh first I just try to write it on everything the problem is there is a one-hour timeout time limit for uh for the uh job and with akonati uh I was around 59 minutes and then sometimes it timed out uh it's always like just pulling the dependencies and doing the initial build takes about 20 minutes so then you are left with only 40 minutes to do the static analysis of everything and I don't think akonati is too big it's not the biggest project and they're definitely not and static analyzers are slow because they do a lot of checking and thinking so uh I realized well I do not need to check the whole code base every time all I need to do is I need to figure out which files have changed on this branch and I already need to check those files so the static analyzer job is now much faster because it only checks the files that have actually changed uh for for errors uh then obviously it runs the clacy and client tidy on those changed files and ultimately it generates a code quality report file initially I was using junit uh format but then I was pointed at the code quality uh format which actually integrates it better into the github ci the major advantage is that you get the report directly in the pull request view of gitlab this is what it looks like looks like so this is a pull request on my test repository and where I intentionally introduced some issues and you can see that I already got two crazy warnings there that I'm missing a reference on non trivial type and that the signal argument needs to be fully qualified so this you get as part of your pull request you see it in the in the gitlab ci in the pull request window and that's that's awesome for both for reviewers and for the developer developer knows that this needs some some more work and and of course the pipeline has failed because of that so you can see that the pipeline is read unfortunately we can't really set at this point we don't have it configured that you could not merge if the pipeline is read I would love to be able to say uh no you cannot merge until the pipeline is green but we'll see back to the yaml file just to show you how what can we customize this so this first the first two lines you know that static analysis is a job definition the extents shows that the job should be based on a template called dot static analysis and then you can add variables and then where you can customize some of the variables which has a default the first analyzer the first variable is called analyzers it's a comma separate list of analyzers so classic like tidy here you can choose only crazy or only client tidy and in the future there might be more checks that you might wish to turn on or off cxx flags you may want to disable deprecated warnings because very often you can't do anything about deprecations so deprecated deprecated warnings because they might be coming from a third party library right so you that this would break your code analysis so you can just suppress them through cxx flags argument which is then passed to the static analyzers and then there are places specific chat arguments which are for please ignore there so if you should ignore anything coming from a particular directory or includes coming from a particular library so in this case usually include we don't want warnings about Qt being wrong as well as for instance in Akronati i've put in there some third party folders or a third party folder because i don't want claysie to do checks on a third party library that we have included or embedded and then claysie checks you can of course customize with which checks you want claysie to run so maybe you want all of them or maybe just want the level of zero level one this is up to you i believe this is the default that i just copy pasted from the from the definition for clank tidy to customize it you just create a dot clank-tidy file in the root of your kit repository i will not go into details how to customize it here you can check the website the home page of clank tidy it's very well documented on how it looks like and what it looks like again what you get put in there uh this needs some consideration and a lot of testing because if you enable just all the checks it will be crazy there even some of the checks are like sort of contradictory because they have there are some like default checks or cpp core guidelines pkpro and statements performance issues these are cool but then there are other google specific guidelines or LLVM project specific guidelines and fuchsia specific guidelines and if those some of those checks they clash with each other so you fix it to to fix to be uh for a google checks to not complain and suddenly LLVM checks start complaining so you need to be really carefully which ones you want uh of course uh the future that i would like to get to is to also include things like qml lint and pylint and rundos on the change to qml files and python files and maybe more uh the code is written in a way that should allow for this rather easily so it's mostly about just introducing some way to convert from the output format of those tools into the code report or code quality format that idlum understands the conclusion unfortunately i wasn't able to finish all of this before academy as i was hoping to uh it's already on pro request to the system in repository but it is not yet uh there uh it works but it still needs some a little bit of polishing and discussion i hope to get it merged or done during academy uh of course if you really really want to help out or try it out and help maybe do some beta testing yeah you can ping me at irc or or or matrix and i can point you to the right repositories where where this lives and what which how you can include it into your repository for testing right now uh ultimately i realized this should be a default for frameworks at plasma uh definitely i would like to work on uh getting those uh as these basic claysie and clang time dystopic analysis uh enabled for by default for all frameworks repositories and uh plasma i i believe depends on uh if the plasma maintainers wish wish to do so but i think at least for frameworks as a sort of one of the flex products we should definitely have that and that's all from me so some time for questions thank you all right let's start with the questions off with question number one can the content of gitlab dash ci dot yml file be run locally somewhat yes uh you can uh download the docker file that's used on gitlab ci uh and then you can take the commands that are specified in the gitlab ci there is a section in the gitlab ci file uh in the includes file there is a section script or script where it actually lists the commands that are executed during the test so if you enter the docker docker container and you copy paste those commands you basically are able to run uh run the checks in the same environment as in which they will run on the on the gitlab ci it's not like that you could just say uh uh it's not like that you could just say you know push a button or run a command it would sort of run your gitlab worker with everything in it that i i haven't found a way to do that okay next question is it safe to run a yml with includes from the internet well if you know where they are coming from i don't see a reason why not okay next question is it a complete optin system or will there be a massive switch in the future where all projects get pipelines automatically um this is i think more of a question to the c70 as far as i know the idea in long term is to move from Jenkins to gitlab ci but i think better some some systems have been answered this this question okay next question then do you have experience with clane static analyzer i think clane to the tidy has some integration with it but i don't know if you can use tidy alone and get all the checks i believe clank tidy has uh i think clank tidy has one of the checks in clank tidy is static analyzer which runs the clang static analyzer stuff so and then it has all these additional checks on top of the clang static analyzer so yes you can run clang tidy uh individually and get the clang static analyzer plus all the rest all right next question can gitlab ci run test yes if you configure it i think uh i think uh the yaml file i'm not sure if this is enabled by default uh in the currently defined sets but actually yes i think it is because some of our projects have failing tests on gitlab ci so yes you get tests run automatically even with if you just include the the yaml file from from sysadmits all right two more questions uh next is will our infra explode doing all the hacks uh it might but that's uh that's one of the reasons why i uh might think that uh or why i went for the approach of doing only checking the files that have actually changed in the pull request so usually i mean sure you can do a pull request with changes everything but usually in pull request you or in your change you only touch a few files so it's reasonably fast so it should not explode okay just crossed all right it looks like we have an eighth question coming in but question number seven is is there a template slash documentation to add to this project and not yet uh i think uh once this all settles and it's merged into uh merged into the sysadmin repository that i definitely write down some uh something on a on a on a wiki so that uh uh anyone can just copy paste it into their own gitlab ci okay great all right last question is still being typed we only have like 30 seconds let's see if we can do it does your thing properly detect changes in headers that rop propagate to many cpp files uh well if you if you change the oh i see what you mean uh i actually do not know i haven't tried just changing a header file and seeing if the study can like to check say that's a good question thank you i'll i'll make sure to to check that