Marek Grzenkowicz: How to Automate Dependency Updates with the Renovate@Roche Bot

In this talk, Marek Grzenkowicz presents how to automate dependency updates using the Renovate bot at Roche. He discusses the challenges faced when joining a data science project with outdated dependencies and how technical debt can accumulate over time. The speaker emphasizes the need for a more efficient way to manage dependencies, leading to an exploration of the Renovate bot, which integrates with various package managers. Marek demonstrates how to configure this tool within GitLab, highlighting its capabilities to create automated merge requests for updates. He also addresses the importance of setting up appropriate configurations to avoid overwhelming teams with too many updates at once and ensuring that the tool aligns well with existing CI/CD practices.

Ladies and gentlemen, please welcome our next speaker, Marek Grzenkowicz, presenting the topic how to automate dependency updates with the Renovate at Roche Bot. Thank you. Thank you for this introduction. Who was here for the 11:00 talk about DevOps 2.0? Yeah, you guys were here, I know. Yeah. So, the rest of you, I guess, chose to be here to see the avalanche of automated merge requests that Eishay

was warning about. I will actually try and promote it and hopefully show you some ways how you can, you know, protect yourself from this avalanche to becoming a problem. But, yeah, there there will be many merge requests merge requests created automatically. So, a while ago, I joined the data science projects project that has been running for 2 years. The developers decided the dependencies they wanted to use,

you know, Pandas, NumPy, Jupyter, spaCy, whatever else they they were using 2 years before, they pinned the versions and they never changed them. So, at the moment when I joined the project, this was already becoming an issue. That was definitely an example of technical debt. And it it took us collectively a few weeks to sort it out because all the dependencies were outdated, Python version was outdated.

However, when we there were many interdependencies between all the packages that were used in the project. So, yeah, it was a significant significant effort to sort it out and make sure uh, all the Python packages are updated to their latest versions. And this is where I thought, okay, there there must be a better way. We cannot only rely on the development team to be diligent and keep

updating the dependencies manually. And this is what this talk will be A better way to keep the, uh, project dependencies up to date, not necessarily in, uh, Python projects. So, I will be using Python as an example, but the Renovate bot, which works with many more, uh, package managers and different languages. I I am from Roche. Uh, Roche is a Swiss pharmaceutical company that was founded more,

uh, than 100 years ago. So, we've been around for a while. Uh, we have two main, uh, divisions. We have Pharma division that discovers, develops, and produces medical products. And we have Dia division that delivers, uh, diagnostic solutions. All this cannot be done with, uh, all this cannot be done with without, uh, IT solutions. Uh, so we have a number of, uh, IT hubs. Two of them

are placed in Poland, where I am coming from. And to be precise, I am coming to you from from Poznań. So, show of hands, please. Uh, who of you uses mostly GitHub for development? Okay. How about GitLab? That's surprising, but very good to hear this is the talk, uh, for all of you, but I think it will be especially useful for, uh, GitLab users. Uh, who uses

anything else? Okay, it will be interesting to to hear what this something else, uh, is. We can, uh, chat about this later. Thank you. So, now I know uh, something about you. Let me innovate Renovate. So, Renovate is an open source tool that allows you to get dependency updates automatically. It's available at GitHub. It's coded mostly in TypeScript. It supports a large number of package managers. I

will not go through this list, obviously. But you will see uh some some examples in the demo I will do later. So, you will see updates for Python. You will see updates for GitLab CI, and you will see updates for Docker images. These are the ones that we I remember off the top of my head. But yeah, here's the complete list of supported managers. You can find

it in the documentation. And if you are using anything that's not in this list, it is also possible It is also possible to configure it custom update managers. So, there are a few options to use Renovate, and the naming convention the vendor uses could be better because there is Mend Renovate, Mend Renovate Community, and Renovate Renovate by Mend IO. And it's super hard to tell just by

looking from the name which of this is commercial version, which is free version, or whatever else. But yeah, that's that's the naming convention they decided to use. We will be talking about Renovate by Mend IO, which is the offering that you can use for free. And you may be interested in this GitHub bot. So, this is a bot that is available in the GitHub Marketplace that you

can enable for your open source project and start using. Or you can use this Renovate Docker image. And this will be the topic of the remainder of the presentation. Uh because I will show you how to configure it, how to configure a using this Docker image when you have a self-hosted install instance of GitLab. And before I get to the demo, uh I wanted to include this

information because this may be misleading as at least it was misleading for me in the beginning. Renovate has a of configuration options and it's really a lot. You can spend days or weeks tweaking your configuration. However, they are split into two separate pages. So, when I will be showing some configuration option and you will want to look it up later and you will go to this link

marked with number one, which is uh configuration options for a repository, that's one place. But you also have more configuration options for the self-hosted instance. So, yeah. Uh this was misleading for me in the beginning. I was looking for some options, not finding them until I learned there are two separate web pages where you need to look. Okay, demo time. Is it big enough or should I

zoom in? Perfect. Thank you. Uh so, I have This is This is uh fresh instance of GitLab. I have two projects I I will be working with mainly and some backups in terms things go wrong. But hopefully they won't. So, yeah. This is This is a dummy project. And I named it this way so my colleagues at Roche when they find this project don't think uh bad

about me. So, this is a dummy project. And the dependencies have are outdated here for a reason. And there is not really much useful There is no useful code here. Uh but let's have a look. Yeah. So, we have a hello NumPy uh script that is importing NumPy. And there is a single function that is only here so uh I have a reason to have a some

unit tests. There is a test that is uh checking uh this uh NumPy function. And that's it. Nothing interesting here. I only need any function and any unit test to to have a CI/CD pipeline. I also have a test and this will actually be useful that checks the Python version that is currently uh used in the environment. And I uh defined this test in a way so

it fails when we are trying to use the latest version of Python meaning uh Python 3.12. Okay, so we have a piece of Python code. Uh what else do we have? We have uh pre-commit checks. So, there are pre-commit checks and if you look here, there are some versions number the version numbers here. And the these are not most recent versions of these hooks. Uh what else?

We have requirements. Again, there there are two requirements here so there is NumPy, there is pytest. Uh not super interesting. Both of them are outdated. And we have a GitLab uh CI pipeline. And actually here we have we have two jobs. So, first we are running the pre-commit checks. And if you are surprised to see pre-commit checks part as part of a CI pipeline I don't trust

my colleagues enough and I don't trust myself enough to believe that everyone will always run the pre-commit checks on their laptops. So just to address this issue, I always include the pre-commit pre-commit checks in the CI pipeline, too. So this is why we have this job here. And if we skip the uh caching part here that I added to make this demo go more smoothly, uh there

is basically this one line that is executed here. So this job execute pre-commit checks for all files. So that that's all that's happening So this is job number one and it is followed by job number two. Job number two installs the requirements and then executes the unit tests. This is not the most This is not the best solution because the requirements are installed every time the job

runs. but yeah, it gets it gets the job done and again I added some caching to uh to make sure it is as fast as possible. In a project that was not a dummy project done for a presentation there are many ways to implement it better. But yeah, long story short, we have a Python project with some dependencies. Uh they are outdated uh for a reason and

there is a CI pipeline that execute two jobs in sequence. Now let's switch to let's switch to the other repository. Uh and actually to make things faster So the this other repository is Renovate Runner. So this is how you can configure your own instance of the Renovate bot. And I will run the pipeline uh Uh, before I explain what the pipeline does, uh, yeah, because I I

don't want us spending time looking at this, to execute. So, this will run, uh, or not. Uh, we need a one quick check because it seems to me that my colleagues disable, uh, the particular runners, uh, I wanted to use here. So, not only live demo, but also live coding. Worst case scenario, I have the backup and we will go through the, uh, static repositories I prepared

beforehand. But, it should be better, uh, if this works. Okay. So, I'm committing this change. Hopefully, this will unblock the and we'll be able to, uh, study what's here. Is it looking better? Okay, this is looking better. Now, Renovate runner. What it means to set up a Renovate runner. So, let's start from the top. Again, we have a CI pipeline. I am using the official image, uh,

from One I was, uh, showing on the slide with the misleading naming convention. So, this is, uh, Docker image from their, uh, Docker Hub registry. And what I am doing is simply calling, a utility named Renovate. That's it. So, CI pipeline is very simple. There's a single stage with a single job and all I am doing is calling utility or method called, uh, Renovate. What else do

we have? If you look closely, there is also a config file here mentioned. So, indeed we have uh config.js. And config.js uh defines that Okay, so we are we are working with uh We are working with GitLab. This is the API endpoint that Renovate should be using to communicate with this instance of GitLab. Uh we want Renovate to create uh on boarding merge requests to onboard the

new projects. I am pointing to the initial onboarding config that I will show in a moment. Then we have a list of repositories that should be scanned by Renovate. And we have a token. So, this is a GitLab token that gives Renovate access to all the projects that it is scanning. And when I say all the projects, I mean the projects that are listed in this repositories.json

uh file, which is having only one project right now. But it could be many, many more. So, this actually uh can be a list that contains more than one uh element. But right now I am scanning only the projects that we are looking before, the one the dummy Python projects project with outdated dependencies. And one more thing that we have here is this uh JSON file. uh

a config file, a Renovate config file that will be used when onboarding new projects. So, when you are managing an instance of Renovate, this is where you can uh decide what will be the initial configuration for your users. So, this is how you can help them uh to have a good configuration. And that means that, for example, uh I propose that all the merge requests created by

Renovate have this label. Uh this is one of the one of the options you can uh decide to use. Okay, let's see how our pipeline is doing. So, the the pipeline was actually completed successfully. Let's have a look. Just to make sure it's not showing some error or warning inside. Okay, there there is a warning, but this is a warning I will discuss in the last step.

Apart from that, it is all looking good. back to the dummy repository that was just scanned by Renovate. We go to merge requests, we see a new merge request. So, yeah, this is the beginning of the avalanche. The The The bots are taking over and creating merge requests for us. Uh one for now. So, let's check this uh merge request. So, yeah, it was created by Renovate.

It says that it detected the following files that are uh let's say in scope that are of interest for Renovate. These are the files that it can be updating. Then you are getting an explanation of uh what's happening here. And then the important thing is you are getting this list, what to expect. So, if you accept this merge request with the current configuration, these are these are

the merge requests that will be uh configured for you. Okay, so, this is pretty good explanation for the end users. Uh I believe this is pretty good onboarding ex- perience. There are also some warnings, and I will get to that. Uh I will address those warnings later, but for now, uh let's merge this. Let's ac- accept this. but maybe first check what was actually here. So, what's

here is this initial onboarding configuration file that we were looking previously in the runner repository. So, I, as the administrator of this Renovate instance, decided that okay, I want to use uh onboarding configuration. And that's exactly what's here. Now, I'm putting on my end user head and I say, "Okay, I want to change something here." So, I will actually This is a merge request. This is a

regular merge request. There is no nothing special about it. Which means that I am reviewing this And I am entitled to make changes if I if I want to change something. So, I want to add some options here. So, basically, I want to add an option that says that I will be the assignee of merge requests created by Renovate in this single project. And I will also

want to enable uh support for the uh for the pre-commit file. So, I I will also want to have this file updated. This is not available out of the box because this is a community-driven feature. But you can decide to enable it. So, I am adding these two two options. I'm also getting some expected comma. Why is it expecting the comma? Oh, sorry about this. So, this

is fine. This is fine. But this was not not not needed at at all. I don't know how it got here. I think now it is fine. Looks reasonable. Let's give it a try. Uh thank you Thank you for the support. and we'll see if it works. Okay. So, Uh, I made this change. Uh this is my this is the configuration file for this Uh, I will

merge this. Uh, now we need to wait for uh for the pipeline to complete or I will merge it immediately to not to wait. So, now the dummy project has one extra Uh, we have the renovate.json config, which means next time renovate will scan and I will trigger trigger this right away. Next time renovate will scan this project, it will have a configuration file that tells it

what to do and uh how to treat this project. Okay, so again, I switch to the runner project and run I am running the Yeah, important thing to say here. Uh, in most cases, you will not be running renovate manually. Of course, you can, but it's usually easier to configure a GitLab schedule and automate those executions run the pipeline every every hour, every 2 hours, whatever you

decide you decide works for you. And I also want to give you a piece of practical advice. Why I always convince everyone using renovate to make sure uh to set the assignee or either assignees or reviewer reviewers Because by default, uh renovate is creating and not assigning them to anybody. And that means that nobody feels responsible for dealing with them because uh either nobody feels responsible or

people are forgetting about them. Uh, people are not getting notifications about new merge requests and if this is a project that let's say is in maintenance mode, that is not actively developed, uh then those merge requests can go unnoticed for weeks. And then why use Renovate if you are not doing anything about the proposed updates? So this is why I believe the uh assignees uh setting the

assignees option to to a name or a few names is is a good thing. How is this doing? Not bad. Okay, completed. Back to the dummy project. What what happened this time? Okay. So it it detected that there are two dependencies that are uh out of that are outdated. So let's see what this what this is showing us. So yeah, we have information that this is a

minor update from version 1.25 to 1.26 uh dot four. We have some warnings. I will explain in a while what they are And we we also have some information what you can do about this. So Renovate in every merge request is trying to uh explain to the end user how to work with the tool. And as an administrator of the tool, you can change this message. You

can put something specific to your workflow here. Let's have a look at the change. So a change was made to the requirements And basically is a uh version number that was bumped. So yeah, exactly as Ishai was explaining, uh the change is super super small. And it's only about changing the the version number. Let's check the pipeline. The pipeline is green. So the pre-commit is successful and

the unit tests are successful. Obviously this pipeline would be will be more complex in a real project. In this dummy one, uh I I that's enough to uh to explain what I am trying to convey. I will merge And the other the other merge request I leave for now. And we'll have a look because there is actually one more thing that was created. So, if you go

to issues, there's a new issue. And this new issue is named dependency dashboard. And the dependency dashboard is showing you about your about this project. So, for example, here we are getting the warnings that some things are not configured. We also the updates are rate limited. By default, I think Renovate creates two update merge requests at a time. You need to merge them or merge at least

one of them and then you will get a new one. I want to change this. in this project I want to allow more merge requests. This is why I will go to Renovate JSON again. I will edit this file. And I will add one more option here. So, I want to change the PR hourly limit. It uses the GitHub naming conventions. This is why it says PR

not MR, but that's the same I will change it to 10. Okay. And there was one more warning And the warning message that I want to address here is the fact that there is no GitHub token configured. Therefore, the release notes are not retrieved. seeing the release notes inside this merge request is very useful. So, I want to address this as well. And to do that, I

need to go to the runner project, let's say to the server side of things. And I need to uh set a variable. So, to make sure that Renovate can pull release notes from GitHub, you need an uh personal token for GitHub uh to to fetch fetch the change logs. And the proper variable is named uh GitHub com token. I have the token already here. I will only

rename it uh to have a proper name. Okay, was it saved? It was saved. So, I will run the pipeline again. Okay. Uh I am anticipating a question. Maybe I am wrong. Maybe it wouldn't be asked. Oh, there are some questions already. but I will look at them later. But I am anticipating a question that Okay, so now I will be getting 10 or 15 merge requests

every day or even more often. How do I deal with that? And could they be merged automatically? Very much to what Eshay was suggesting for such trivial merge requests. And the answer is yes, they can be merged merged If you trust your CI pipeline, if you trust that your that your CI pipeline uh catch any issues, uh will catch catch any issues that could be caused by

uh some dependency changes, you can uh you can have those merge requests merged Actually, I will show you the actual rush instance of mm Renovate. Uh so, this is the Renovate runner that we actually use at Rush. It is also updating itself. So, it is the the same project, finding updates, and then it is merging them So, there there is an auto merge option, and you you

can decide if you want to do this for patch releases or minor releases. Or if you Or if you are really brave and you want to do that for major releases. I I I think that you you could also add major here. This is why when you when you add Look And yeah, Renovate is releasing very So, if you have a look here, so this was 6

days ago, this was 1 week ago, 1 week ago, 1 week ago. And these are mostly updates to All right, there are also some other packages updated, but mostly these are updates to Renovate, and they are all merged automatically. As soon as the pipeline is green, uh the merge request will be merged, and I don't even have to look at that. But, back to our project. Is

the pipeline complete? Yes. So, what do we have now? Now, we have many more and we need to we should obviously wait to see if they breaking the pipeline or not. But, yeah, I tested it a few times, so I know which One of them will fail. I know which one. So, I will merge the remaining ones in the meantime. But, before because I configured the GitHub

token, there is one important Now, we have the release notes inside the merge request. And from my perspective, this is super useful feature uh because yeah, that's that's my that's my usual morning. Um I usually start the day by uh scanning the merge request that were created. And I yeah, depending on how important this the dependency is, I spend more or less time going through the release

notes, understanding if any of the changes is uh affecting the application. And based on this, deciding whether I can simply uh merge this or I should spend some more time testing the application with the updated dependency. These two are very minor. I fully trust them, so I will merge Now we are getting to more interesting stuff. So, it proposed an update, and this time it is updating

this GitLab CI file. It bumped Python from version 3.11 to version 3.12. uh the pipeline is red as a result. I can see why. Okay, what's wrong? You probably remember there was this unit test that was explicitly forbidding this version of Python, and this is why we have this message here. you can do one of two things. You can adjust your application to become compatible with updated

dependency or updated Python version, or you can close such a merge request. So, I will add a comment and close this. And here I have an information that for Renovate, that means I want to ignore this uh version update, and I won't be reminded about Python 3.12.3 again. It will not recreate this merge request in the next run. However, uh it will create a new new merge

request when version 3.12.4 is released. But, it will not be bugging me about this particular version of uh Python because I decided to close this merge And then we have pytest, and here we have something interesting because we a sep- two two two separate uh merge requests for the same package. So, we have a proposal for the patch update. And this is a change to requirements.txt. And

we have a proposal for a major update. Uh this is this is a change to exactly the same file, but this time to version oh. So, when you have a major release and uh patch release, for example, you are getting separate merge requests. And of course, there are configuration options to uh tweak this behavior. I will go with the And I will keep the other one because

I want to show you uh what happens now. So, I am rerunning the pipeline. It's 2 hours later. The schedule kicks in again. Uh I did some work in my uh project. I closed the single merge request. I I uh think I merged three other merge requests. I left one open. And let's see what happens now. Where's the pipeline? Okay, it is running. And this will take

a moment to run. So, I can use this ti- I can use this uh advertise the uh Renovate community. It's a really good open source community. Uh, when I post and I post quite a lot of questions to to their discussions discussions board, uh, I always get an answer. Sometimes it makes sense. Sometimes it requires some further further clarification on my side. But it's a very lively

uh, community. So, I can recommend it highly. Very often these are the maintainers who are engaging in these conversations. So, that's uh, that's super useful. And I can also highly recommend there's the setup of the repository. Because I once uh, implemented a change. I once submitted a pull request to Renovate because I needed a new feature that was not implemented. This thing is coded in TypeScript. I

know nothing about TypeScript. Absolutely nothing or JavaScript. So, I was expecting to spend spend the first few days setting up all tools necessary to do uh, TypeScript development. And yet uh, the the it wasn't that way. This is how I learned about dev containers. So, basically they have a dev container here defined. As soon as I cloned the repository and opened it in VS code, it automatically

uh, downloaded all the uh, required dependencies in and in 10 minutes I was able to start coding my pull request. So, yeah. I highly recommend it. I highly recommend this tool and this community uh, also when you if you would like to become a committer. They're super friendly. Okay, what happened here? Because the Renovate run is done. Okay, no open merge request. As you remember, I left

one open. But it has been closed because Renovate detected, "Okay, you decided to use Pytest version 8. So, this proposal no longer makes sense. So, Renovate also take care of uh cleaning after after itself. And if we have a look at the merge request I closed manually, where is it? It was the Python thing. If we have a look here, I am getting Here we have a

comment uh which is a You don't have a comment. Okay, sorry. I need to enable comments from both. Okay. Now we have a comment that reminds me that because I ignored this merge request, I will be not bugged about this particular update anymore, but I will be reminded about the about the next one. Uh okay, one last tweak to the uh because the time is running short,

but we still have the information that it failed to look up this particular dependency. And this is a dependency from an internal registry. This is a dependency from the Codurance Com GitLab instance. And uh one more change I can make on the server side and that's important you do it as Renovate administrator to make life easier for your user users is to configure access access to different

external registries and repositories. In this case, it's an internal Docker So, I am adding this uh snippet here. Okay, again I have a problem with the bracket. That's looking good. So, basically I am adding a host rule and this is a host rule that uses some GitLab CI variables not to reveal any details, uh but this is basically a host rule that says that when you are

updating Docker and the images are coming from a particular registry, and this is exactly this registry that we have here. Use these credentials. So, I will commit this. So, this is a configuration change, right? You you may have a long list of host tools here configuring credentials for Docker Hub, for GitHub, for some internal registries that you may have in your company. I will run the pipeline.

And because the time is running short, I will go back to the slides. Oh, it is running automatically because I updated the file. So, I will go back to the slides and then we'll come back and see if this change worked Anyway, that was a lot of information, I important takeaways from the Just to summarize and just to let you what I would like you to remember

leaving this room. So, first of all, Renovate both gives you automated dependency dependency updates for different packet package managers and different coding languages. Uh, self-hosted Renovate instance, if you want to run your own instance, maybe it's simply a GitLab project. You don't need a dedicated server, you don't need a dedicated infrastructure. If you have self-hosted GitLab, you can use it to run Renovate. Uh, Git will store

your configuration GitLab CI you will use to define and schedule the Renovate pipelines and GitLab runners will run the scans. That's what you need in terms of And also, Renovate fits right into your exist existing development process. So, it creates merge requests, you need to review those merge requests, or you may decide uh, to merge them automatically, uh, but it fits into the process you have, it

fits with the CI/CD pipelines that you use. Running Renovate at Rush, so the the these are the this is the graph for the Renovate bot users that we have. it was a perfect streak as you can see. I don't know what happened happened in October. We must have some uh GitLab uh GitLab downtime and it was turned off for the entire day because in general this bot

is have making hundreds of contributions every day. Uh we are scanning more than 1,000 projects right now. The pipelines are scheduled to uh run every 2 hours and they they run automatically. Nobody needs to run them manually like I was And to scan scan this number uh of projects and to fit in under 2 uh we are running uh 12 jobs in parallel. So so this is

how it looks at our scale of this Renovate uh instance and yeah, what I learned while maintaining Renovate Rush. So first of all first of all you need to invest into simple onboarding process to convince your users to start using the tool. So they cannot be forced to go through pages of documentation to be able to add Renovate for their to their project. You need to promote

the tool constantly and educate your users and remind them uh they should enable it because it's it's not so obvious at first as it turns out. You probably see that I love Renovate very much uh but not everyone is as enthusiastic about this as I as as I am. Yeah, you should be helping your users to customize your project because sometimes the user will tell, "Okay, I'm

getting too many merge requests. I am getting them too often." And they disable Renovate completely. While these are all simple configuration changes. Yeah, you will I need to check the Renovate logs every few days and scan them for new warnings and new errors uh because yeah, the users are very creative in terms of what they add to the to their projects and different new issues pop up.

So, you need to be on the lookout on the lookout for them. Renovate will not fly in projects that don't already have DevOps practices So, for So, for example, a CI pipeline and running unit tests is a must to detect updates that could be uh breaking for the projects. When you have a lot of repositories to scan, you can uh parallelize them uh using the parallel job

option and you can run the scans uh many scans at the same time. And yeah, you should also invest some time and this goes back to point number four uh to configure access to different internal and external registries, repositories, package indexes so that uh Renovate uh can fetch them all. this is something I discovered very recently. When you have onboarding or update merge requests that were left

unattended for months, this slows down the scans significantly because Renovate updates those merge requests and it is become it is taking more and more time to fetch them uh through the GitLab API. So, you should be also looking out for this. Not to have too many very old uh One last look One last look at the demo. The warning is back. Uh I'm sorry. The warning is

gone. there should be Yeah, this is one merge request. This time after adding this Renovate was able to propose update for Docker image that is stored not in Docker Hub, uh but it is coming from an uh internal Roche registry. One more merge request to to be merged. And that's all I wanted to share. If you're interested, all the code I used, all the materials, all the

and the slides are available at this link. Thank you. Yeah, but still we have like minute or two, so let's go through the most rated like questions from Slido. Uh automating dependency updates by creating merge request is convenient. What is your option opinion about going one step further and auto merge non-breaking changes? Absolutely. I do that. believe that your CI pipeline is robust enough to catch all

the problems that may arise from some non-compatible dependency update, uh go for auto merging. And I do that in different project, it works. Maybe the last one question or two which is also top rated like three, so I will catch your minute or two, so uh I hope you can can stay here. Can it fetch release notes from the Yes, there is an option to configure packages

that should be updated together. And you can uh there are many ways to do that. You can list the these packages explicitly or you can create a regular expression, and then you will be getting, for example, updates from LangChain and different LangChain related projects as a single merge request. There is an option to do that. Should I take one more? If you can uh shortly like answer,

so yes, please do. Uh how often Okay. So, how often does the tool create new pull request request after the previous one was rejected? So, it creates a new pull request when a new version is released. So, if you reject 3.1, you will not get a merge request until 3.2. Okay. Thank you. Actually, yeah. Please share your warm applauses like to the Mark, yeah, for his like

presentation. And thank you actually audience for your active contribution with the questions. Here is a small present from organization. Thank