Episode 881 transcript

FLOSS-881

Jonathan: [00:00:00] It's time for Floss Weekly. That's the show about free Libre and open-source software. I'm your host, Jonathan Bennett, and today we're updating. In fact, this is a topic that was not on my radar, but one of our listeners, thank you to everyone out there, said, "Hey, you guys really need to talk about Update CLI." And I said, "I don't know what that is, but we'll send the email."

And so we emailed Olivier Vernon, who is our guest for today, and we said, "Hey, we would love to talk to you about this." And he said, "Sure." And so we've got him on the show. Olivier is the guy behind Update CLI, and unfortunately, I just got logged out of my email address that has his bio. Let's see if I can get back into that. We're doing it live, as they say. But let's go ahead and bring him on, and then I'll get back to the bio. Olivier, welcome to the show. Glad to have you here.

Olivier: Thanks for having me on the show here. Yeah, I was really [00:01:00] glad to hear that you would contact me. So, I've been following what you did here for a few years, so that's really nice to hear. For the BIOS, quickly to talk about me, so I'm working, so I've been working on open source software for the past 10 years, both professionally and on the side as well.

Jonathan: Mm-hmm.

Olivier: I've been contributing to open source conferences and so on, so the biggest one is probably the FOSDEM for those people who know what FOSDEM is about. And so, the reason why I'm

Jonathan: Oh, okay. Mm-hmm.

Olivier: here today is because I was interested to talk about that side project that I've been maintaining for five years, which is all about updating your Git repositories, and so, yeah, that's why I'm here. I don't know if, yeah, the project is named Update CLI, so for people who are not familiar with this, it's kind of interesting because there is no, like, similar project, but it's a CLI.

I mean, you can guess based on the name. That allows you to automatically update your Git repositories based on [00:02:00] manifest that tells you how to update those Git repositories. So the purpose is really to help you on the maintenance of your projects, and so you stop monitoring third information coming from the web. You just define, okay, you have a Git repository.

What would be the latest information, URL, version, whatever? So, people usually, when they think about Update.cli, think about Renovate or Dependabot, which is kind of the closest, I would say, project for what it does, and otherwise, it's just bash scripts, Python scripts, and so on, so it's kind of a seed between the two worlds.

Jonathan: It's amazing to me to see, like, how much of the world is run by nothing more than a pile of Bash scripts.

Olivier: Yeah, exactly. And it's like, yeah, Bash is really awesome, until you reach some limitation.

Jonathan: Oh yeah, absolutely. there are elements of it that drive me crazy um and in fact there is a uh several years ago we interviewed another project called amber that they were like [00:03:00] we love bash except for this set of things that's terrible about it so we made our own scripting language that compiles down to bash code it's like well that's cool um okay so what's what is this what does this problem look like like at what point does someone reach for update cli what where in like an open source project or just

you know your your homebrew whatever it is you're doing what what does the problem look like

Olivier: So, the problem was, back then, like five years ago, when I started working on a project, I was working at the time on the Jenkins project. We had a lot of Git repositories, Java libraries, and so on, and one of the projects which is still running today is the infrastructure where we run the Jenkins, where we test Jenkins, and so on, and so all that infrastructure is managed by infrastructure as code, like Puppet, Kubernetes, and so on, and one of the

Jonathan: Mm-hmm.

Olivier: problems I was facing back then was, quite regularly, someone would build a new application, and then I would forget to update that application on [00:04:00] the Puppet infrastructure, or Kubernetes

Jonathan: Gotcha. Mm-hmm.

Olivier: infrastructure, and so on, and the thing is, back then, I was already using tools like Dependabot, or Renovate, but the challenge is, those tools can understand a file that is well-structured. Like, if you think about, I don't know what language you're most familiar with, but let's say you think about GitHub. GoLang has those GoMod files where you specify the list of dependencies. That's a file which is pretty easy to understand because you can have a tool that runs automatically there and bump those versions. That's where Renovate, for example, shines. But the problem is, quite

often, you have those bash scripts, for example, where you define a version, a variable with version set to something, and it's just impossible to automatically update that bash script because you have some meanings. I mean, you know the purpose of the bash script because you wrote it, and now you need to maintain it over time, and the problem is, quite often, you have a lot of pieces of information hidden [00:05:00] everywhere and you need to coordinate, and so, instead of having, like, Dependabot to bump one PR, what I do is I say, okay, I'm monitoring this application version. That's

exactly how it started. I'm monitoring this application version, let's say the account app, which is a custom application, and now, based on that information, what I want to do is I want to update my Puppet infrastructure, but only if there is a Docker image matching this tag. And I also want to open one PR for the Kubernetes manifest at one time. So, I don't want to have, like, three different PRs. I just want to have, like, one PR that I shoot at once. And so, that's how everything started. So, the idea was really to say, to define what my update strategy looks like is I say, here

is information that I'm looking for, like sources, and then you have, like, different kind of source, but the source is where the information is coming from. That could be a version, a random string somewhere in the internet, whatever. That's the information you need to reuse. And then you have the condition that needs to pass, like, do we have a Docker image? Do we have a file, a Docker file with [00:06:00] that information? Do we have README, whatever it is? And then do we have a target? The target is what you want to update. And so, once you have this manifest that tells you, here is

what my ideal update scenario is, then each time you run update scenario, which is a command line tool, it's idempotent. The result is always the same. You run it from a CI, for example. And then every time it runs, it will fetch all the latest information, verify that your Git repositories are up to date, and if it's not, then you just open a PR, and then you can run it.

Review this, and then the lifecycle of your project keeps working. So, the challenge is really about how to maintain a lot of Git repositories without having to remind yourself to go fetch all those information. And when you think about this problem, it's something that is a really huge problem.

Jonathan: Mm-hmm. Oh, sure. Yeah, because a lot of open-source projects, they do, they define, you know, their various libraries and their various dependencies inside [00:07:00] of their build scripts or, you know, various places. Sure, yeah, it's something that I deal with in some of my projects as well. I think we use Renovate for this, which works most of the time. Most of the time, it works 99% of the time, right?

Yeah, so what did, did Renovate not, no, you said Renovated existed. What was the, what was the big differentiator? What did, like, Renovate lack that you really wanted to solve?

Olivier: So for me, the biggest limitation was having the flexibility to really say, first, to run the tool whenever I need it. That's one thing. And the second one, to really be able to say, here is a complex pipeline. And when I say complex pipeline, I can, for example, provide another example.

Jonathan: Mm-hmm.

Olivier: When I build the update CLI, I create a new release of update CLI. Let's say version 0.1.0. The way it works is I use a super cool project, which is GoReleaser. GoReleaser is responsible to create the packages and [00:08:00] so on to publish that information somewhere. And then at the end of this, I use GitHub Action that sends notification to other Git repositories.

And those other Git repositories, for example, one, for example, contains the handshots, if you're familiar with Kubernetes. One contains the documentation, if you're familiar with running Yugo and your websites. And so the way it works is on those repositories, I trigger update CLI. Based on a hook. And then update CLI will automatically retrieve the latest version of my application, update the documentation, update the Docker image, update the handshot, literally update everything, and then start other processes.

And so it just allows you to run, like, to monitor information, run shell commands, and in a specific order that really allows you to just think about whatever ecosystem you want to work on.

Jonathan: I'm curious: have you thought about or run into the the git tag problem? And this is sort of a security issue [00:09:00] that we're seeing in a lot of different cases. The idea there being that If, you know, if someone malicious takes over a remote repository, they can delete and then replace a git tag really, really easily, and so I've seen people start to recommend that instead of, you know, include this git tag as your dependency, you should instead say include this git hash as your dependency.

And I get it on, like, the security side, that makes a lot of sense. It seems really cumbersome, though, to work with. Is that something that you've thought about as part of UpdateCLI? Is there a solution there, maybe?

Olivier: So, that's definitely something I thought about many times, and we experimented different things. So, before I go into that specific, so we can better understand this, Update.cli is like plugin-based. Like, you can interact with a lot of different plugins, and so, for example, you have a plugin for git commits, like you mentioned, and then you can say "please monitor the latest git commit", or you can [00:10:00] say, like, "please monitor the latest docker image tag", for example. And specifically for the git commit, but that's the same thing that would happen, for example, to any OCR artifacts, like docker images. Usually,

it's recommended to use Digest, but the real issue with Digest is, as a human, Digest are just impossible to review. Like, you receive a PR, you have, like, a bunch of Digests, and then you just merge blindly, and in the end, from a security perspective, you're not really reviewing anything anymore, because you're just, like, trusting the automation, which is something you should never do, anyway.

And that's why we try to use both. So, for example, usually I like to specify the digest, because at least I'm sure what version I'm using, or what piece of information I'm using. I also like to use the commands that specify "this digest corresponds to this information". So, for example, in GitHub Action, for example, you can specify both information, and then me, as a human, I can just quickly check if the version [00:11:00] really matches the commits.

And then you have tools that also allow you to verify these things. Like, I don't know if you're familiar with the project Zsmore, if you're familiar with GitHub Action. So, Zsmore is a kind of a linter that you could use for GitHub Actions, and then it allows you to verify if your GitHub Actions are well configured. And one of the things that it checks is: does the version you specified in the command correspond to the git commit? To be sure that you don't have a malicious actor that just tells you that it's a version 1.0.

that just tells you that it's a version 1.0. And in the end, it just pushes a random commit. So, yeah, the digest is something very tricky. I usually recommend to use digest, but also try to provide as much information as I can to allow humans to verify this, because in the end, otherwise, it's meaningless.

Jonathan: Yeah, it all seems like the the best solution here is going to be to add some metadata, maybe as a comment, or, you know, it's hard to say exactly where, it's going to depend upon the language you're working with. But, you know, your metadata would be, here's the tag, [00:12:00] here's the version we think it is, and then the real thing that you go out and you grab is the hash itself.

That way, you know it's not going to change if somebody doesn't update, but then you have also got that tag information, so where you can watch and, you know, "Hey, you're running v1.1.1 based on the metadata, v1.1.2 is now available, do you want to update your corresponding hash to match?" Yeah, that seems like the best of both worlds, and if you're running a plug-in system, probably that's something that could be managed fairly easily.

Olivier: Yeah, yeah. And there is another concept which has become quite popular over the last years, I don't know if you heard about this, it's the idea of cooldown dependencies. So, the idea is, instead of always updating to the latest version, you should specify your small threshold, like one week, three days, it depends on the ecosystem and how often you want to be up to date.

But the idea behind the cooldown dependencies is, if a malicious actor gets access to one of your dependencies, it's going to take a few days, maybe a few weeks, for the community to realize that something [00:13:00] wrong is happening here. And so, instead of updating to the latest version as soon as possible, then you need to get the, maybe wait one week.

This also comes with limitations, and that's one of the things that is very interesting to work on in this field is, you need to fit to every ecosystem. Every ecosystem comes with different APIs, they expose different metadata, they sort information in a different way, which means that having a tool like Dependabot that just works in most of the case, the reality does not

Jonathan: Mm-hmm.

Olivier: because it will probably catch only a few of the scenarios. And sometimes you need to be able to specify and say like, okay, I need to update at this frequency with all those information altogether, opening one PR. I also know that I would like to add additional information because for this specific scenario, I'm getting like a changelog coming from this endpoint, which is not a standard behavior, but that's everything.

Jonathan: like, node NPM packages [00:14:00] update very differently than your C or C++ system packages,

Olivier: That's all we have, basically.

Jonathan: and it's useful to have one tool that sort of speaks both of those languages.

Olivier: Yes, and the thing is, and that's a tricky That's another tricky problem here is when you think about one of the early design decisions I made with Update.client because that's something I really want to have is I wanted to have a standalone tool. So I choose Golang because I love Golang ecosystem. I wanted to have a standalone tool. I could run the same command from my machine or from CI.

That's my learning from managing CI infrastructure is that you should be able to run the same commands from both locations. The result should always be the same. I didn't want to maintain a state. So I don't have state file like Terraform, for example, because it's a constraint that I put on myself since the beginning. Sometimes that makes things a bit more difficult. But at least if you run the same command as me, the result will be exactly the same.

You will open exactly the same PR or [00:15:00] you would open update the same PR. But the thing is, yes, when I'm talking about ecosystem, every ecosystem comes with its own tooling as well, and the purpose is not to reinvent the wheel. And so, the approach that we made is, UpdateCLI is kind of a framework, like you can use, you can write manifest to update your scenario, but sometimes we just shell out to a command, because we don't want to reimplement, like, for example, YARN, or NPM, or C++ tools.

So, for example, the way it works is, you can say, here is just a file, like, for example, NPM, it's a JSON file, you update the JSON file, and then at the end, next step is, if the JSON file was modified, then please run these commands, and if the final package of JSON was modified, then open a PR.

And so, you can have both of the two scenarios where you can, I mean, you can really have a lot of flexibility in the way you design your pipelines.

Jonathan: I know this is tool [00:16:00] abuse, but it comes to mind: can I use Update CLI to keep a system up-to-date through, like, RPM packages?

Olivier: That's a good question. I want to say yes and no.

Jonathan: Yes, you can, but you shouldn't, is probably the answer.

Olivier: Yeah, exactly. The challenge is, what should be the latest, how do you monitor the latest version? Like, for example, for RPMs, you need a database that you need to query. That's a question I've been asked multiple times, because people love immutable Docker images, and they would like to be able to specify and to kind of re-implement the NixOS, where you can just list the dependencies and so on, I know people using FDCLI in that context with NixOS, but yeah, it also comes with limitations.

Jonathan: Yeah, so you wrote it in Go, right? What was the thought process behind Go, as opposed to, I don't know, C++, Python, Rust, Bash, any of [00:17:00] the other options?

Olivier: The thing is, because I'm working, I've been working in infrastructure for a long time. I've been working with communities for a long time. So Go is kind of the default tools we use in cloud environments. And you also have a lot of libraries. So it's super easy to use. One of the things that I love with Go is you have a lot of conventions.

So we all write the same codes. So if I look at someone else's code base, it's pretty easy to read. Today with AI, it works quite well as well because the code it can generate is kind of the standard generated Go codes. So that was easy. And the other thing that I really love is it can generate binaries.

I mean, statically linked binaries, but binaries for every distributions. That means that when I work, I mean, you can use a baseline with Mac OS, Linux, Windows.

Jonathan: cool. Do you have an idea of how many people are out there using UpdateCLI?

Olivier: It just works.

Jonathan: [00:18:00] It's very hard to answer most of the time, yeah.

Olivier: It's very hard to tell, because the thing is, Update.cli is designed to run in a CI, so I can definitely give you numbers, because those are public. You can see, for example, from So, I think it depends what numbers you look at, but I think I have basic telemetry for Update.CLI, so, for example, when Update.CLI runs, it checks what's the latest version, and for that, it queries a JSON file, so I know, like, how many times Update.CLI created a JSON file, and it's something like probably 600 executions per hour.

So, somewhere, somewhere in the world. So, that's the current ratio. It's like, we have six, seven updates in execution every minute. No, yeah, that's probably the best matrix that I have. Otherwise, the number of downloads is really huge. But once again, because it's executed in CI, how [00:19:00] many of them is really human? Like, I think, I like to use, for example, matrix for Darwin, like for macOS, because macOS, You never use Mac OS and CI probably.

And so I have something like maybe... Two, three hundred downloads for every version, but for Linux and Windows, it's a lot more, but once again, it's difficult to tell.

Jonathan: Yeah, because I mean, we all start with the same CI image on GitHub, and then you install your tools inside of it. And so, you know, every time that runs, it's a new download. Yeah, that's a fair point. When people run this, how often do they usually run it? Is it like once an hour job? Is it once a day job?

Olivier: Once again, I heard different thresholds. The reason for that is because people have been using Update CLI for many different kinds of use cases. So, I know, for example, I saw a blog post from someone from Elastic [00:20:00] who is using it to automate documentation updates, because you can use it, for example, to update all your URLs, version, installation page. I know people using it in the context of development, where they just want to meet on go-lang dependencies, or like Java, whatever. I know a lot of people using that in the GitHub space, where you can update Argo, Cd, Flux, and so all those different kind of people have different usage.

And usually, I would identify two kind of updates. You have the updates that you monitor that are part of your core business, like, for example, if you build a custom application for your company, you probably want to get the latest version in your infrastructure as soon as possible. On the other side, if you monitor, let's say, the latest Python version, maybe that's something you can wait once a month or every two months.

So, usually, depending on the team, they have different habits, and they try different things, because if you update everything very regularly, like every hours, it just creates a lot of noise, and then you stop working on the main feature of your [00:21:00] application. If you update them, like, every six months, maybe you have, like, technicaldebt.com, and then it takes you a lot of time to update.

So, it's really, I think, it really depends on the project, the maturity of the project, how much tests you can rely on, and then the team experiment with that. Like, sometimes it's one day, and then they realize it will change that every two weeks, every month. I mean, even for me, some projects, I did that every day, and others, I just wait a few weeks or months.

Jonathan: You've got a note here in the prep document that this gets used by companies that are not software vendors, like banks and hospitals and governments. I'm very curious: what does that look like?

Olivier: The usage is pretty similar to any other organization. For example, I met a person, and then the first time we did a presentation about how UpdateCLI is used in a hospital in Paris, it was the first time for me to go to a conference where someone was talking about the project, and it was not me, which was really awesome.

Jonathan: Yes.

Olivier: [00:22:00] And then we did another presentation together. A lot of organizations rely on open-source software. A lot of organizations maintain used Git repositories. A lot of organizations develop software, and so UpdateCLI is kind of the tools that you use in your project to automate and to simplify the maintenance of your project. So, I know companies in the banking center, I know companies in every different kind of industries, which I find also super cool.

Jonathan: So, essentially, they're just watching for, you know, they've got their list of open source projects that they use on, I don't know, end user desktops to run the website, all these different things, and they just, they fill it in, and they've got a list inside update CLI, and run it once a week or whenever, and, oh, look, there's a new version of, you know, all the different things that they use, whether it's, I mean, I could I could think about this, and it's like, you know, if a bank is using a certain [00:23:00] backup program, let's say, or, I don't know, I mean, there's all kinds of options, but like, oh, hey, there's an update for that, you get a ping, we should probably go and deploy that, it's probably time.

Olivier: Yeah, and sometimes they use it this way, but they sometimes also use it to monitor internal products, like when you have a pretty big organization where they develop a lot of custom applications. I like, for example, I find it quite useful. I built a UI on top of the data. It's something experimental that I would like to get rid of, but it's helped me to visualize, for example, the state of my different projects.

So, Update CLI, for example, I was telling you the example of the release automation. Like, I can go to my UI and tell me, like, okay, what are the pipelines where the label release Update CLI, and then I can see that, okay, I already update, and the PRs are merged on the documentation repository, but I still have some pending PRs on [00:24:00] the Kubernetes repository, and I still have some pending PRs on the GitHub Action repository. Because of this, it will automatically monitor my application. I know that when I do release a version of my application,

it will automatically monitor my application. I know that when I do release a version of my application, it will automatically monitor my application. I know that when I do release a version of my application, it will automatically monitor my application. I know that when I do release a version of my application, it will automatically monitor my application, it will automatically monitor my application.

So, when I do release of Update CLI, I would just quickly have a look to the dashboard to see, okay, am I all good with the updates? Is this update already updated everywhere, or am I behind with this work?

Jonathan: Is there is there any support and update CLI for the idea of a staged rollout?

Olivier: For what? For runouts?

Jonathan: Staged rollout? Like, I've got a new version, but I only want 20% of my users to use it right now, and we'll wait a couple of days.

Olivier: No, no, no, no, no. It's not something that makes sense. I don't think it would make sense in the case of Update.cli, because you will probably rely on the tools that you use. Like, for example, Argo CD can do rollouts. And so, Update.cli can update your Argo CD configuration, and then Argo CD is responsible for this. Update.cli is really focused on "give me the right information", which is already a big challenge, because different ecosystems come [00:25:00] with different versioning, and sometimes the same piece of information can mean different things. Like, for example, semantic versioning is 1.2.3,

but you could also have a date where you just have, like, one digit, a dot, digit, and another. So, that could be, like, a huge date, or that could be something totally different. So, like, being able to monitor this information is, like, the first challenge. The second one is when you want to reuse the same information across different ecosystems.

Like, in one PR, you want to update maybe, like, Infrastructure Manifest, Dev Manifest, and Documentation. Maybe some of the tools don't support that. Maybe you need to replace that by underscore, and so on. And so, that's how you end up in a situation where you need to first identify right information, and then you need to propagate that information. And there is just Even things like what's the meaning of the latest information, like "latest" means nothing, like for you, "latest" could be the latest version from a semantic versioning point of view.

That could be the latest from a date perspective, and just the notion of knowing what's the latest is super [00:26:00] difficult, and even within the same ecosystem. Like if, for example, you think about what's the latest Docker image for Update.cli, if the same image is hosted on Docker Hub or on GRC or Natalio, the answer will be different, because those two Docker registries implement the API in a different way.

One will be sorted by date, the other will be sorted by a lexicographical order. And so that means that the latest information is really, really difficult to get. And so that's why Update.cli focuses on what's the latest information you want to have, is your current repository correctly up-to-date based on the definition you specify, And finally, can we provide you the right information so you can make the best decision about merging the PR?

I mean, you could automatically push to the main branch, for example. I saw horror stories around this in the past, so that's not something [00:27:00] that I would recommend. But yeah, those are things you could do, definitely. You can sign commits, I mean, yeah.

Jonathan: Yeah, I was humored thinking about this, the semantic versioning. Semantic versioning is just a recommendation, and even the projects that claim to use semantic versioning, they'll sometimes break stuff in the minor updates. It's like, no, no, no, that's not how this is supposed to work, but it's the world we live in. So yeah, I would at least recommend making sure that your CI run goes green before you automatically push that bump.

Olivier: Yeah, and what is fun when you maintain a project over time? Like, for example, we've been using Update Selling and Jenkins for five years to manage infrastructure. What is fun is you end up trusting some vendors, because you know that they respect semantic versioning, and there are some vendors you never trust them, and you always review carefully why they change or why they bump something, because it can always break.

And that's one thing, and the other thing as well is sometimes some [00:28:00] dependencies are more core to your project than others, like... Do you want to bump the notification mechanism? If it's not critical for you, then just bump it, and then you will see if something breaks. But if it's a core functionality of your application, then you may want to spend more time to verify.

Jonathan: Yeah, yeah, absolutely. Do people actually just let update CLI run hands-off?

Olivier: Yes. Like, usually you put that in a CI,

Jonathan: Well, no, I know that, but I mean... You get to the point where it creates the pull request, and then a human goes and reviews the pull request. How many people run it and just YOLO the pull requests? Like, I don't even have to review it, just make the pull request and then merge it immediately.

Olivier: That one is something I don't really have metrics. Obviously, I don't really have a lot of visibility. Usually, what I see is people use auto-merge feature. Like, for example, on GitHub, they will automatically merge the PR if the [00:29:00] tests are passing.

Jonathan: Mm-hmm.

Olivier: I know for sure that that's something kind of fun. I already had people who just want to commit directly to main. So, they've been asking me for that kind of features in the past. It's not something that I recommend. That's something I Try to avoid, but once again, I don't have that level of telemetry, so I mean, I don't have telemetry on the project, so...

Jonathan: That's a hard decision to make on your part, because it's like, "This is such a bad idea. Don't do this. I have people that want this feature. I hate the idea of this feature. Like, what do you do? Are you going to give it to them, or are you going to stand your ground and say, 'No! Don't go directly to Main or Master!'"

Olivier: No, I usually, for me, the project is like, I don't try to judge how people are using the tool. Like the purpose is to have something flexible enough so it can fit your pipelines. So if it's something, so the way I approach that kind of decision is, is it like, is it something that costs me to implement?

If it's no, then [00:30:00] I don't care. I mean, you can use it. You are responsible for what you do.

Jonathan: Yeah. Have you heard any horror stories about people getting themselves into trouble using UpdateCLI?

Olivier: I've warned you. I've warned you. Sometimes there are situations where you can just commit directly. But yeah

So, I have an horror story on this one, and that's something that affected me for one month, something like that. I was using it, I was working on another project, and then one day I woke up and saw, like, I didn't touch the updates in like four weeks. Like, no release, no recent release, whatever. But one day I woke up and saw, like, thousands of PRs opened by updates, like, over the night, with thousands of emails.

Jonathan: Oof.

Olivier: And so, basically, everywhere, on every place where I was using updates, it was auto-merged on. Like, it would open a PR, run the test, merge the PR. Something changed on GitHub's [00:31:00] side, where... Object CLI would clone the repository, detect that a change is needed, push the change to the repository, to the remote branch. There, GitHub would allow me to open a PR that contained no change, because there was nothing to change, because the repository was already up-to-date. All the tests would pass, then it would merge, and then Object CLI would run a git clone command, see a previous hash, a previous commit, then detect that there is an update, push

to a new branch, open, run the tests, nothing needs to be merged, because nothing changed. GitHub would merge the PR, and then again and again, and because of this, CLI was configured to automatically run when something changed on the main branch. It just did that, and I discovered that GitHub does not allow you to open more than 100 PRs by similar PRs, and so it blocked after 100, and I was like, so yeah, I have a huge amount of empty commits, and that's something that would only happen via the API. Like, I tried [00:32:00] to reproduce that using the UI, and it was not possible to do,

but via the GitHub API, something changed, and then it lasted for one month. I tried to find a way to fix this. I was like, okay, now Object CLI is not usable anymore, and then one month after, everything was back to normal, and so I guess that GitHub made an update, and it was over.

Yeah, exactly. And that's something that really frustrated me at that time, because GitHub is kind of the host for a lot of open source projects, but GitHub is not open source. You have no idea what they are changing. It's just a black box. It's a convenient black box, but it's a black box.

Jonathan: Yes, and I've had this struggle before, because we've had things break inside CI, not quite that spectacularly, but we've had things break inside CI, and it's like, you go and you try to even find, where do I open a bug report inside GitHub for some of GitHub's tooling, and that's difficult to find, and then you open the bug report, and, you know, there's 517 [00:33:00] other bug reports that haven't been touched in the last three years, and, you know, oh, I'm filled with confidence that GitHub is going to fix this.

It's really a pain. If GitHub wasn't free, and so good, it would be really terrible. There's a weird dichotomy there, where it's both the best tool in existence and terrible at the same time.

Olivier: Yeah, exactly. But yeah, I still...

Yes, and so, yeah, I also use GitHub Action, and many people do, but that's why I said, like, I like to have some guardrails when I work with CI, and I like to be able to review, and when I enable auto-merge features, when I automatically merge PRs, those are usually for changes that are not, like, big deal.

Like, for example, if it's a PR that updates all the installation links to the latest version, then I just auto-merge that, because worst-case scenario, I introduce a broken link, and someone will complain, [00:34:00] and I will fix it. But, for example, if I need to update one of the core libraries that it depends on, or if I need to update one of my infrastructure components, this is something I want to review carefully, and to be sure that I merge the PR at the right time, when I have the time to look into the consequences of my change.

Jonathan: Does Update CLI have kind of that idea of a tier system, like this particular dependency is super important, tread carefully, versus this other dependency? Yeah, you can probably YOLO it.

Olivier: No, also, the... Once again, yes and no. Out of the box, it's no, because it's difficult to define. You need to come with this. So, the way it works with UpdateCLI, it's a command, and then you can specify parameters. You can say, for example, run UpdateCLI. So, basically, the way it works is UpdateCLI, apply, and then you specify a configuration, and then you can specify parameters that say only pipeline IDs matching, blah, blah, blah.

And so, for example, for pipelines that I want [00:35:00] to update immediately, I specify a label within my manifest that says "monitor:active", and so that means that I have an UpdateCLI job that runs periodically, like, every hour, and I only update those pipelines with those specific labels. That means that I decide one of the information that I want to have.

I just want to update it as soon as possible. And so, I have different execution of update CLI, those that focus on releases, so, for example, if I have a new release, I will run update CLI just on manifest with the label "release". I use active monitor to update those that I really want to have the latest version as soon as possible, like, for example, Golang version.

And then, for everything else, I just update like every two or three weeks, because I don't have the time to deal with all those notifications. So, to answer your question, yes and no. Right now, update CLI is really a tool that you can fit within your infrastructure, and then you customize the way you want to use it.

Like, are you using Jenkins? Sure. [00:36:00] Are you using GitHub Action? Why not. Do you want to use something totally random implemented using Cloud yesterday evening? Why not.

Jonathan: So, you

Olivier: It's really up to you to decide how you want to use it.

Jonathan: can you can bring it into GitLab, Codeburg, any of those other alternative sort of Git interfaces, and it works just fine.

Olivier: Yes, yeah. Yeah, exactly. So we support pretty much all the Git providers out there. Obviously, depending on the Git provider, we don't have the same level of features. I'm using GitHub, so GitHub is the one that is the most advanced, but we support all of them. Something that is also interesting with Update CLI is, as I said, you have this concept of manifests. I keep telling you, you write a YAML file where you specify source, condition, and target.

But we also have different kinds of updates. We have this idea of auto-discovery. So in that case, it's a smaller manifest that you write and you say, you know what, please identify all the dependencies related to Golang. And so then Update CLI [00:37:00] will automatically parse your Git repository, find every GoMod file, and then do something similar. Similar to Dependabot, where you can just detect all the dependencies and updates, and then you can say, only update this GoMod file based on the path or a matching version or whatever.

That's, I would say, the next level for those updates where you can just let the tool detect everything, and we also have the ability to have shared pilot policies, and so, for example, it's kind of useful when you have, like, a lot of Git repositories to maintain, and in that case, the way it works is you I mean, you still write WCLI manifests, you put them on an R registry, like docker hub, ghr.io, whatever, and then instead of having the manifest locally on your repository, you can just specify your URL, and then you can just reuse the same URL from multiple repositories, this is version, you can use it in many places, and that's also a way, for example, to manage, like, CodeBorg organization, GitHub organization, and so on.

So, you don't need to write manifest for everything, because we [00:38:00] already have a bunch of manifests that you can just reuse in a generic way.

Jonathan: I- I- No, go ahead.

Olivier: But in the end, everything in the back is an updated CLA manifest.

Jonathan: I have this sort of cursed idea about where I might run UpdateCLI, and that is: on a server, in a cron job, looking for the things that are supposed to be deployed on the server, waiting for them to update, and just automatically going out and grabbing it and making it live. That's slightly cursed, but at the same time would be a really nice thing. I don't have to SSH into it to update things anymore.

Olivier: Yeah, exactly. That's one of the ways, like, I have a server where I do this, exactly. I have crunch jobs, and then I run update.cli, like, once a week, and then it just updates my manifest, and, um, definitely.

Jonathan: Oh, I may have to do that. That's actually a really clever idea. It's kind of cursed, but it's also awesome.

Olivier: The, the, and, and, and, yeah. The thing is, that's really manifest, [00:39:00] like, allows you to update either git repositories, and if you don't specify git repository configuration, you just modify the files locally.

Jonathan: Yeah, that's...

Olivier: Yeah, definitely, that's a use case.

Jonathan: So, you could probably then also, because it's plug-in based, you can also say, "And after you've done this update, restart this systemd service."

Olivier: Yes, exactly. So, the way you define these kind of things is you can usually have one source, like you monitor one information, at least one.

Jonathan: Mm-hmm.

Olivier: What you can do is you can say "monitor this information", or multiple one, you can also change those sources, and then you can have one or multiple targets. A target could be, for example, of carrying a docker file, and so you say, like, you reuse my information, update my docker file, and then you have a second target that says "please run these docker commands" if the first target was modified. And so, that's how you can change, you can really change, chain, sorry, actions, and having like very advanced update [00:40:00] scenarios, and now, yeah.

Jonathan: Yeah. Yeah, that's neat. It's not the thing that you had in mind when you first wrote the tool, but it's a really

Olivier: That's something that is sometimes fun, because people, I mean, usually, when people come to updates, it's because other tools failed them. And then sometimes come to me with, like, super-weird updates in REO, and I'm just like, Yes, that's something you can do. Is it a manifest that will be easy to maintain? I'm not sure. At some point, maybe just re-implement everything in Python, because it's just too

Jonathan: We've mentioned

Olivier: weird. But, yeah, you can do a lot of things with the Blitz.

Jonathan: it a couple of times using the AI tool when you do stuff. Pick your favorite AI agent. Is it pretty good at writing the update.cli.yaml files?

Olivier: Yes, and the reason [00:41:00] for that is because one of the advice I received many years ago from the community is, I don't know if you're familiar with the Gizem schema and Gizem schema store, but the idea is, with an update CI, we generate automatically a Gizem schema that we published on a specific endpoint, and then your IDE can use that schema to validate your manifest.

That means that when you write a manifest, you can just go to your preferred IDE, and as long as the update CI manifest matches a specific file name, which is documented on the website, you can just do crunch hold space, and then it will suggest to you what are the parameters and keys that you can use and how to use them.

And in your AI, you just use exactly the same thing. Like, for example, I was really surprised in the past where I would just make a release of update CI, and open another PR on a totally different repository, leveraging that new release, and then GitHub Copilot would complain that the parameter is wrong because [00:42:00] I'm not allowed to use that one in this.

And I was like, oh, of course I forgot to update the Gizem schema because there is this PR still pending, and I need to merge this one. And yeah, it works quite well.

Jonathan: If only, if only there was a tool that could watch your releases and remind you to go update that schema. If only such a tool existed.

Olivier: Exactly. Yeah, exactly. So, that comes back to the validating, to merging, because when you use this tool at scale, you end up with, like, having hundreds of repositories, and sometimes you just forget, like, where you are and what you still need to do. That's why I believe the next step is definitely to work on that UI that I would like to make it stable enough to use. It's still an experimental feature right now.

Jonathan: Yeah. Yeah. So, is there—this is kind of an interesting segue into this question—do you commercialize this at all, or is it just sort of a labor of love and something that you use internally?

Olivier: So, that's something that I used in Shirley for quite a long time. I don't have a commercial version of Updates Eli. [00:43:00] That's something I've been thinking for a while. But yeah, right now I just receive sponsoring. So, I receive sponsors for some companies, and sometimes that sponsor goes up, sometimes it goes down, so it really depends. But I don't really have a way to commercialize this. But yeah, that's something I would like to find a way in the future.

Jonathan: Sure. You work currently, your day job is OpenSUSE. Do they give you any support for this? Do they let you work on it during your day job hours?

Olivier: To make the development of this more sustainable.

So, I'm working for Sioza, as you're right. I'm working for Sioza as an engineering manager. I already have a lot of work. I can sometimes use it, work on it during my day-to-day, because a lot of teams already use it within the company. So, it depends on the feature, but I'm already busy enough with my main work at work. So, it's already difficult to find some time to do this.

Jonathan: Yes, I 100% understand. And it's one of those deals where it's like, if it's the thing I was [00:44:00] paid to do, it probably wouldn't be fun anymore.

Olivier: That's why I said, like, it's... I had mixed feelings for many years, because on one side, I had a lot of fun working on this, and the more I worked on this, the more I realized that there are more things to do. But when you start working, and you start to be paid for something, then the relations change, and you have to do things.

And that's something that I really love with the project today, is I use it on many of my projects. I know many people using it, so I try to keep this as stable as possible. And I don't try to change the manifest, because if I change the manifest, then that means that I need to go on a lot of my Git repositories to change the pipelines.

So, I try to keep this as stable as possible. And, yeah, because more people use it, it's really nice to see.

Jonathan: Update CLI project use Update CLI?

Olivier: Of course it does, since the beginning. Of course [00:45:00] it does.

Jonathan: Eating your own dog food. Love to see it.

Olivier: I think it's the only way to work on open source, to be honest. That's something that every project should be doing. If you develop a solution, you should be the first user, because that's something that You feel the pain. There are things you design because you believe that it's a very important feature, and it turns out that you use less because of whatever reason, and sometimes there are things that you really find painful.

For example, the JSON schema I was explaining. One of the early pains I was facing at the beginning was that I would just work on updates until I implemented a lot of new ways to configure things, but I had to update the documentation, and then I would forget myself about how to configure things. And then I would always go back to the code because I was like, "The documentation is outdated. I don't want to write documentation. It's really boring."

And then I had the opportunity where I could generate that JSON schema that would generate the documentation, and that made [00:46:00] things a lot more easier because now I can just modify a comment in the code, and then it will automatically update my documentation. And those are small things that you only feel when you work, when you use your own projects.

Jonathan: Yes.

Olivier: And sometimes, Jonja,

Jonathan: There's this thing that happens in open source projects a lot. I've seen it myself. It's like the guy that does all the work tends to, at some point, stop actually using the thing. And so you then get this statement made a lot in open source, like, "Yeah, I'm the main maintainer for it, but I don't really use it anymore."

It's such a weird thing that that happens so often. I'm not sure that's entirely healthy when that happens.

Olivier: It's not healthy, and also that's why usually on Update.cli, I just encourage people to contribute, and they can own some of the pieces. Like, for example, Update.cli supports different Git providers: Stash, Bitbucket, Azure DevOps, and so on.

Jonathan: Mm-hmm.

Olivier: Usually, I know the people who need those, and they usually contribute [00:47:00] to those features. I know the people, some of the contributors who have been using GitLab, so if I have any doubts on GitLab, I would just ask them to review a PR, provide feedback, or whatever. And that's why I usually prefer people who contribute to Update.cli who are real users.

Because if they tell me, like, "I would like to have this feature for GitLab," I want to say, "Yeah, sure, go. You can use it." But if I'm not sure, and all you did is just ask Cloud to generate a feature, so you can put it on your CV that you contributed to an open-source project, then it's a lot more annoying, because I'm not sure if you will be using the feature, and if you're not, then I just need to maintain some dead codes that nobody uses.

Jonathan: Right.

Olivier: use.

Jonathan: Yeah, nobody wants to maintain dead code. That's not a fun thing to work on. I did pull up the UpdateCLI GitHub here, and I see a few interesting things. First off, you have 107 contributors, which, definitely, that's good. It's not just two or three. I love seeing that. The latest [00:48:00] commit was made by UpdateCLIbot, which, again, we're dogfooding here.

Olivier: - Yeah, I think, I think if they said I commit probably something like 80% of code to the repository all the time. It just, yeah. And it's not only dev dependencies. It's like, if you look at the README, I think the instructions will tell you to use the latest version directly. The URL will be good. If you open a GitHub issue, for example, on the Update CLI, it will automatically suggest you the latest version.

Because, like, everywhere we have a version or an information that could be outdated, we use Update CLI to optimally bump those information. So, it really allows you to maintain a project over time. And because of the level of automation, I did a lot of releases. I think I did something like close to 250 releases for the past five years. And doing a release is super easy.

I just have to push a git tag, and then it starts the process, and then it takes [00:49:00] me something like one hour to complete the release process. But I'm not even watching the release process. It's just, like, pipeline going, and then I just know that I need to double check. That everything is still ongoing. But otherwise, usually, it's super easy.

When you have a right level of automation, it's just super easy to use.

Jonathan: I'm curious, looking at, again, the open pull requests that you got and such, I'm thinking about this, and it's like, this is a tool that's going to be used by developers, and so it sort of seems like you probably have a bit of self-selection going on, that you're going to get higher quality pull requests than, you know, compared to a tool that is made for the everyday person as opposed to the developer. Is that something that you've seen? Do you feel like you get good quality pull requests?

Olivier: No, no, it's really not .

Jonathan: No, not at all.

Olivier: Most of the time, most of the time, yeah, no, no, no. Most of the time, I definitely receive very good pull requests, but at some time, I receive PRs, and I'm just like, [00:50:00] what's the point? I mean, you open a PR just to rename something that provides no value, and you just run one hour of tests for nothing.

Jonathan: Yeah.

Olivier: That's something that I saw with AI over the past year, is sometimes people open PRs, and it looks good at the first time, because you're like, okay, it contains documentation. It contains tests, it contains codes, and then you start reviewing the PR, and then when you try it, you realize that it cannot work because of whatever reason.

But the problem is, you already spent like 30 minutes, one hour reviewing the PR, like I already started my evening working on this, and now I'm like, I mean, it's easier if I just fix the PRs, and then merge it, because in the end, it started with a good motivation, like the person wanted to fix a real issue on the project, but something that already happened to me many times is like, I have something, I want to implement something, and then I try to ensure that PRs don't stay I usually try every day, every few days, to review [00:51:00] those PRs, and sometimes those, that time, drag me away from my initial work that I wanted to do, or finish.

So that's why I was like, is PR always good quality? No. Most of the time, yes. And I'm really happy to receive those PRs, and I'm really grateful for the people who contribute to the project. But sometimes I also have that feeling where I'm just like, you should read what the code was produced, because it just, I mean, you look really weird on this.

Jonathan: The funniest thing I've ever seen is, we had somebody open a bunch of PRs, and we're finally like, "Dude, you need to stop this, you're opening too many PRs," and his response was, "Oh, I didn't realize that the AI opened all of these PRs."

Olivier: That was the moment when I realized that... Yeah, I remember one day... So,

Jonathan: Yeah, that was a scary moment. That was the moment when I realized that the world has changed, and it will never be the same again.

Olivier: One day, so you have different ways to show something on the console [00:52:00] in Golang. And one day I received one PR where a guy just renamed one of that. I don't remember which one, but it was like just renaming the way it showed the information to the console. And I was like, what's the point to open a PR just for teeth?

I mean, it does not change. It does not provide value. It does nothing. It's really useless. It's just a taste. Like, do you want to use one way or the other way? I mean, from my perspective, I don't really care. The reality is we use both. But now you run this. You spend like one hour of CI to run all the tests and so on.

And... I mean, it's just useless. And then, for some reason, I had to run the test again, the CI again, and then I just closed the PR, because I didn't want to spend time merging this kind of... PRs that do not make sense, and sometimes I also receive PRs where it looks easy at the first, but then you realize that it touched something core to update CLI, and then you need a lot of time to test and to validate, and you need to introduce a very nasty bug, and you [00:53:00] can really quickly end up spending your evening working on something

that wasn't expected, which is annoying.

Jonathan: Yes. Do you, I think you mentioned this earlier, but do you have the feeling that some of the PRs you get are just people trying to mine for "I want to be active on GitHub and a whole bunch of different repositories"?

Olivier: That's the feeling that I have from time to time. You cannot really tell for sure. Because, Update.cli is in that sweet spot where it's big enough that I have enough contributors, but it's not like that 30,000 GitHub stars where everybody wants to contribute to it. It's very niche, because the challenge with this project is something, like, I talk from time to time at conferences, so I maybe do one talk about it once a year or twice a year,

Jonathan: Mm-hmm.

Olivier: mostly in Europe, because I'm based in Europe. So, outside of the people working on Jenkins, or colleagues working on SUSE, and the people around me, or attend [00:54:00] the conference where I go, I don't really have a huge marketing budget where I can just travel the world and keep talking about the project. It's still a very small project, and taking the time to promote it is also like a full-time job.

I mean, there are people paid for that kind of things.

Jonathan: What license did you go with? I saw it, and now I can't remember. Apache 2.

Olivier: Apache 2. The licensing open-source project is a difficult decision to make. It's an important one, and it's a very difficult one. So, the first time I went with MIT, because I wasn't sure what to choose, and then I decided to go with Apache 2 to align, because all the projects that I'm working on are using Apache 2. That's what the Linux Foundation is recommending.

The purpose was really to make it as open as possible, and the Apache 2 license [00:55:00] sounds like the best one. For the UI, for the backend and the UI that I'm currently working on to make it the Udash project that I briefly mentioned, this one is GPL. A-GPL, I think. And the motivation is, I want to make it clear that if I find a way to monetize a project, that would probably happen with a web app, with a platform.

The CLI, from my point of view, should be open and forever, because the biggest value of it is that the more people integrate, the more people add use cases, the plugins, and the better it is, because even for me, it allows me some time to have update scenarios that I didn't work on, and just because I received a contribution that is useful to me.

That's why this one is Apache 2. But I'm not a lawyer, so maybe I'm wrong.

Jonathan: Yeah. No, no, I think that makes sense, and I'm glad to hear that you're looking at the AGPL for that for that particular use case. You know, we hear stories about, I guess not quite so much anymore, although I'm sure it's still happening, [00:56:00] but like some very big projects were getting undercut by, like, Amazon. So, like, you know, you would have a database project, and you had an offering where, you know, the database is a service, and then Amazon would come along and sell the same database to everyone for, you know, half of the cost of what you were selling it.

And so these guys, like, their revenue stream just deteriorated overnight, and they started doing things like, Source-available licensing, like the Business Source License and those things, not open source for various reasons, and I, at the time, I just, I constantly wanted to know, like, why not the AGPL? That's exactly the sort of thing that it's made for, and so I'm glad to hear that you came across that when you were aware of it, and that's kind of the direction you're going, rather than one of these other less recommended, less recommendable licenses.

Olivier: Yeah, I don't like those other licenses, and something that I find a bit sad is when you re-license an existing project where already a lot of people contributed to. [00:57:00] And so, that's why I was like, I want to try to find the best issue. Maybe I was wrong. Maybe, I mean, my only story will tell me if I was correct, but that's why I made this decision. But as I said, it's not an easy one, and the reality is you don't have a lot of people to talk to these kind of challenges. Like, how do you license? What is the best one to choose?

And how do you protect your project, your work as well?

Jonathan: Yeah, I have been lucky to have met a few people that are literally experts in this field, and it's still a difficult decision sometimes. Have you gone the route of like a contributor license agreement, a CLA, to be able to go back and make changes to the license if you needed to?

Olivier: No, that's also something that... I don't have a contributor agreement.

The reason for this is I want to keep it as simple as possible to contribute to the project, and I try to avoid those [00:58:00] those extra work, I would say, on an open source project. That's one of the other things when you think about, for example, donating the open source project to a foundation. It also comes with paperwork, I would say, where you have to have a governance and so on. And those are important topics when the project goes big. But in this case, there is no VC behind me. It's just a side project that I'm working. So I don't need to protect from actors where the motivation would go in a different direction from the project.

Jonathan: Right.

Olivier: Because in the end, once I mean, I've been working on open source like professionally for a long time, and it's a tricky balance to find between business objectives and the open source objectives. Ideally, from my perspective, it should work in a symbiotic relation where the two can contribute to the lifecycle of the project and to the business.

But sometimes there are situations where it becomes more difficult to find the right relation. But I don't have that kind of problem today, because I don't have a company behind, [00:59:00] and I still have a main work, so my... I just... Yeah.

Jonathan: It is the lower-stress approach to not have a company behind the project, for sure. All right, so we've gone through quite a bit. Is there anything that you want to let folks know that I should have asked you about? Is there anything that we didn't cover that we should have?

Olivier: That's a good question. Well, I think we covered quite a lot on the project. So, if people are interested, yeah, the project is hosted on GitHub, so they can have a look. If they have any questions, we use Matrix. So, we have a Matrix channel if they want to reach out and ask questions, and all the feedbacks are more than welcome if you want to experiment with it, and make suggestions. Like, if there is something you would like to see different, yeah, I would be glad to hear from you, because once again, what is really difficult with open-source software is to get feedback from the users.

Jonathan: real

Olivier: Um, because you never know who's using and, [01:00:00] uh, yeah.

Jonathan: users. Don't just let your AI come and open up issues."

Olivier: Yes.

Jonathan: Alright, now I've got to ask two final questions before I let you go, and, well, I guess it's three now. So, the two questions that we have historically always asked is: what's your favorite text editor and scripting language? And just last week I came up with a third question that I think we really need to add, and that is: which AI agent do you prefer for writing code? So, those are the three that we'll end with.

Olivier: So which ID am I using? So I usually like to use NeoVim for most of my usage.

Jonathan: Uh-huh.

Olivier: And then I use VS Codes where I'm really into programming activities. Like when I work, for example, with Update.cli or another project, I usually have VS Codes. But for any other use cases, I have NeoVim because the reason why I like NeoVim is it can also have autocompletion. So for schema, if you write [01:01:00] in Siebel, if you write Update.cli, GitHub Actions, you can configure in a way where you get autocompletion, validation, and so on.

Jonathan: Nice.

Olivier: So for me, it's like NeoVim and VS Codes.

Jonathan: Pretty cool.

Olivier: The second question was, what was it about again?

Jonathan: The favorite scripting language.

Olivier: So for me, my approach with scripting languages, I used a lot of them in the past. Usually, I love Bash. I mean, that's my default way to go. I use Bash for a lot of things. As soon as I find my Bash to become too big, because whatever reason, and then I start to have too much complexity there, I usually switch to Python.

So for me, it's very common. I have like a big Python script that called Bash as well. But I try to keep Bash as simple as possible because Bash allows you to write a lot of weird stuff and you should not use those syntax because it makes it difficult for any newcomers to read them.

Jonathan: Yes, this is true.

Olivier: So, that's why I like to switch to Go, and then if it's Go one step further, I love, oh sorry, Python, and then I switch to Go. So [01:02:00] that's, I would say, my level of complexity based on what I need to do. And what AI agents?

Jonathan: Yeah, if you have to write or review code and you want the AI to do it for you, which one do you turn to right now?

Olivier: Right now, it's the one that sponsored me. So, right now, I'm getting some sponsoring from Anthropik. So, I use Cloud for two months. I'm quite happy with the usage of Cloud. It works quite well, and I was able to fix a lot of annoying bugs, and also work on a lot of those small things that are super easy to do, but just takes time, and so with Cloud. In the past, I was using GitHub Copilot, because I received a license as part of DataCity, because it's an open-source project, and I was able to fix a lot of annoying bugs, and also work on a lot of annoying bugs.

It turns out that since they changed the way they measure and count tokens, I kind of stopped using it in June. For me, it's unusable anymore, so for me, GitHub Copilot is not something that I'm looking at now. Unless to review some PRs, but I [01:03:00] find it very unreliable, in the way that I never know how many tokens I will be using, and I have a mixed feeling with GitHub Copilot. And otherwise, it works. We have everything else.

Jonathan: I will say, just because we've had really good success with it, CodeRabbit, for doing PR reviews, is actually quite good, and it's been around for a while, like several months they've been offering it as a free service to open source projects, and it's actually pretty good. It's worth looking into.

Olivier: Like, SUSE provides us a lot of AI, and then we experiment with the different things. So, GitHub, yeah.

Jonathan: They've got a paid version for commercial projects, but if you're open-source, they'll get you set up for free.

Olivier: Okay, nice. I will have a look.

Jonathan: Yeah, if that's something you're looking for. Alright, Olivier, thank you so much for being here. It's been a blast to get to talk to you about all of the crazy things that we can do with Update CLI, and I legitimately will have to get this running on a couple of different [01:04:00] places. I'm looking forward to it.

Olivier: Thanks, thanks, thanks for having me, that was nice.

Jonathan: Alright, thank you, sir. Yeah, absolutely. All right. That was Olivia Venen talking about UpdateCLI, the surprisingly capable and flexible plugin-based Git updater to Track releases, update your code, all sorts of stuff, a lot of fun conversation there. We do have a show next week as well. We're talking with Jan Altenberg and Alexander Barr of the Open Source Automation Development Lab, and then we're taking the week off after that because I'm going to be traveling, and then we've got a couple of slots open. So if you or somebody you know needs to be

on the show, let us know: floss@hackaday.com, and we will make it happen. We'll get them added. Other than that, I just want to say thank you. We appreciate everybody that's here. Those who get us live and on the download, and we'll be back next week on Floss Weekly.