OSGeo
[Feat] CI: limit noise by Renovate updates
Currently, Renovate generates almost daily updates on some CI action. One such update triggers a PR, which someone must approve, and subsequently merge. This means at least three emails for someone that signed up to watch the progress of this project!
The number of commits to main that only updates the actions in the last three months amounts to 94, that is around a quarter of the total number of commits [^1]. This causes unnecessary noise and maintenance work, which only distracts from really important events for the project (and frankly, not a small amount of irritation on my side).
I suggest to put the Renovate on a schedule, with updates perhaps monthly or, better, every quarter of a year. If some action is broken in between, we will probably notice and it can be updated manually.
[^1]: Calculated with git log --oneline --since=2024-07-08 --grep="CI(deps): Update*" main | wc -l vs. git log --oneline --since=2024-07-08 main | wc -l
I should add that the unnecessary noise also regards to the commit history.
Would you want to try weekly before that? Or twice a month? We should at least keep the lock files weekly preset, that keeps the nix cache updated weekly, and tests that build weekly.
I'd say default to quarterly, and exempt whatever needed for nix to weekly.
There's also the 4 docker image pins (instead of moving tags) that could just be free whenever to be able to use the respins when they are re-published (the packages are updated, and is most useful for security patches). These are done about once a month each, so being quarterly would mean security patches up to 3+1 months after the docker image respin, that doesn't happen immediately too.
Given this another thought. What about default to quarterly, with nix and docker monthly? Let's get this ticket moving, please.
Quarterly and monthly sounds good. Is there a setting to get, e.g., high-severity security updates right away?
The renovate bot is also our largest contributor in the last 2 years in terms of commits. That's probably okay, but I find it funny.
I would need to read if there's something to do to get security updates right away or it just does that by default. Otherwise, all PRs can be created with the Dependency Dashboard PR, they will be in a section "awaiting schedule". So we can create them on a case-by-case basis if needed.
GDAL chose monthly dependabot updates.
@echoix In the light of upcoming summit, do you want to reduce the frequency of some of the updates?
@echoix In the light of upcoming summit, do you want to reduce the frequency of some of the updates?
I was also thinking this may become a very irritating issue. Last time I checked it didn't seem to be so easy though. If that is the case, we can consider switching it off temporarily.
For now, it is only on weekends. So, starts before the summit, and we can turn off for the last Saturday if needed.
I have some ideas for adjustments to the required checks that we can use for the duration of the developper summit. I can't do the changes by myself, so we can do it first thing when the summit starts.
Essentially, removing the requirement of the "Success" jobs, but hardcode the individual jobs that they guard against. That will prevent having the required checks ready for version changes (that changes the name of the check).
We can also disable one of the 3 pytest checks, like for Python 3.12.
We could change the docs builds to use CMake for saving a 2min45 build time (on a 12m job), if it works the same for the docs and addons rebuilt for docs support it too.
We could also see if gcc17 standard checks could use CMake. These are single job, and are quite long (maybe for nothing).
Same thing for Python code quality checks, since the actual build is not really useful, only the gui+libs are really useful for running Pylint.
For the duration of the summit, maybe the Ubuntu minimal config matrix jobs could be disabled too.
Builds for pylint, docs, and pytest could also make use of ccache as it is not that important if there's a weird issue resulting from a build using ccache (not rebuilt from scratch).
Additionally, I could micromanage and cancel some of less needed jobs queued on main, if we have a lot of activity and a following commit would check it anyways. If there's a failure and we need to find which commit started failing, we could restart the individual jobs.
I'll make the weekly updates later tonight/this evening, a little early than usual. There's ruff (usually releases on Thursdays) and super-linter (released earlier this week, releases once a month) for now planned.
Updates are made weekly, only during weekends, or manually triggered. They are not bothering or consuming CI time during the week. They are (usually) handled by me in the weekends when I'm available to take care of them. It seems a good compromise, and haven't had more feedback on this since. I'm considering this addressed.