Skip to content

Conversation

@thompson-tomo
Copy link
Contributor

This upgrades the renovate preset to follow the best practices rather than just the recommended as outlined in https://docs.renovatebot.com/upgrade-best-practices/

The difference is the addition of the following profiles/rule-sets:

  • docker:pinDigests
  • helpers:pinGitHubActionDigests which has an override to preserve readability
  • :configMigration
  • :pinDevDependencies
  • abandonments:recommended

In effect this gives us insight packages which have been abandoned, allows for automatic migration of legacy config options and also rules for dev dependencies.

This also aligns the settings with what the spec repo uses https://github.com/open-telemetry/opentelemetry-specification/blob/main/.github/renovate.json.

@thompson-tomo thompson-tomo requested a review from a team as a code owner November 20, 2025 10:48
@thompson-tomo thompson-tomo changed the title Update Renovate configuration to best practices build: Update Renovate configuration to best practices Nov 20, 2025
Copy link
Member

@pichlermarc pichlermarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This repo is very delicate with its dependencies.

Essentially I agree most of what this PR is doing except for the catch-all :pinDevDependencies - we have a lockfile so that the few devDependencies that are unpinned don't cause havoc.

@thompson-tomo
Copy link
Contributor Author

Would it work if we add an explicit don't pin dev otel package rule?

@pichlermarc
Copy link
Member

Would it work if we add an explicit don't pin dev otel package rule?

Could work. But also I think we're kind of okay with the settings we have now. Though, we may want to have our actions pinned, and potentially images pinned too as we did in the core repo.

Other than that I don't think we necessarily need this change and I suspect blindly applying best practice settings right now will make us spend a lot of time sorting though issues that don't really move the needle for anyone. I'd leave it to folks that regularly update dependencies in this repo and have a feeling about what usually goes wrong with these sorts of things.

@thompson-tomo
Copy link
Contributor Author

So what prompted me to look at this was the fact that markdownlint was not reporting violations. What I saw was markdownlint was out of date and was pinned on the old one. I know from other projects pinning dev dependencies resulted in them being updated.

I can make the exclusions to include anything that is currently not pinned that way we have a central list.

@thompson-tomo thompson-tomo changed the title build: Update Renovate configuration to best practices ci: Update Renovate configuration to best practices Nov 20, 2025
@pichlermarc
Copy link
Member

So what prompted me to look at this was the fact that markdownlint was not reporting violations. What I saw was markdownlint was out of date and was pinned on the old one. I know from other projects pinning dev dependencies resulted in them being updated.

The problem here is not pinning. We have dependency Dependency Dashboard approvals on for most packages.

We don't update all packages at once since we have a massive amount of them here in this repo. We found that:

  • auto updating packages individually takes time away from reviewing contributions made by real people.
  • auto updating package in batches makes it pretty much impossible to troubleshoot when something goes wrong, you'll have to update on a package-by-package basis anyway.

Both approaches burnt people out as they had to deal with dependency updates all day. Some worked immediately, some did not. But all of them took visibility away from actual PRs people opened. So I pulled the plug on it and made Dashboard Approvals required. That means that if somebody has a few minutes to spare and they have Triage permissions on the repo, they can trigger and update and work through any problems without it always being shoved in their faces that they have to do it. The downside is that some packages get less love than others, but IMO that's fine as long as it is not security-critical to update the package.

Since markdownlint is not really mission- nor security-critical in our case, I'm fine with it being outdated for a bit if that means that means we can work on things that actually helps folks instead. It's hard enough to find the time for that already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants