[recommendation] Ensure renovate is enabled and configured on all OTel repositories

[adrielp]

Overview

As part of the security slam, issue #87 outlined the need for pinning dependencies in GitHub actions to hashes. There are a couple solid ways to accomplish that in the short term, but in the long term there's a need for continuous pinning and updating in a way that maintainers and approvers are enabled to understand what the actual changes are, and require minimal overhead to gather that understanding.

Renovate is a means to accomplish this. Many of the repositories already have a measure of renovate configured. However, some do not. While it may seem that repositories like opentelemetry-specification have a low footprint, they still at minimum import packages in GitHub actions and other tools. Tools that can be run locally through NPM, and tools that reach out with GitHub tokens through actions.

This is a request to ensure Renovate is configured appropriately everywhere. With GitHub Action pinned dependencies especially, this helps ensure that when new actions are added, they will automatically be pinned on version update by Renovate.

[trask]

many repos are using dependabot, I think that also supports pinning also?

[adrielp]

many repos are using dependabot, I think that also supports pinning also?

I thought it did, but I'm not finding a clear reference to it in the configuration docs. However, looking through issues and source code, I found the original issue and pull request. It looks like it only does it if it's already been set to the SHA with a comment. If not, it'll use the current version.

I think based on that information alone, Renovate provides better security. Maybe we should standardize on using Renovate as the tool for repositories within OpenTelemetry?

[trask]

It looks like it only does it if it's already been set to the SHA with a comment.

oh, will Renovate automatically change

actions/checkout@v4

to

actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

[ms-jcorley]

I'd be all for taking a deeper look at these tools and make sure we are using the right ones, but I'd want to be careful not to hop around for specific features, i.e. churn for small gains or some-better-some-worse.

With that caveat, Renovate does seem to have a lot of upsides:
https://docs.renovatebot.com/bot-comparison/

[adrielp]

@trask - yes.

@ms-jcorley - agreed. I've done extensive research in the past (admittedly it's been a while) and written some docs internally where I work on this. Dependabot, while a nice starting place, just isn't as good as Renovatebot. Of course, having Dependabot enabled for security updates specifically, isn't bad to leave enabled even if using Renovatebot, but universally, I think Renovate is a better tool to standardize on across the board.

The collector used to use dependabot, but went to Renovate largely because dependabot fundamentally didn't support the file size configuration necessary to support their use case (grouping dep updates by components lead to a larger than allowed dependebot.yaml). While there is a noise issue when using the default config, it's pretty simple to adjust it and they provide great guidance.

They also allow the use of custom managers. A custom manager was built specifically for the OpenTelemetry Collector Builder (ocb) which almost makes it the required tool for maintaining a distro.

I have yet to find a con that makes dependabot win the race. Happy to write up a proposal w/ some of the information I've found if this is something we want to have tracked.

[ms-jcorley]

@adrielp In the end I'd love to have, not so much in proposal format but as an end product, brief documentation for future generations on why we've chosen Renovate so that every time a new person asks why, we can point them at our reasoning. I think we'd want to have this for each tool we recommend as our 'standard'.
It would be great if you are willing to write up something for that.

I'm currently focused on the vuln management side of things, so I haven't thought too much on the format for the supply chain security documentation, but eventually I see something like a high level doc that is just the enumerated list of tools/configuration settings recommended (required?), but it has links to sub pages that explain the why for those who care.
Maintainers who just want to follow the recipe can just read the top level doc and execute on each item.
Those who want to argue about the merits of a specific item can read the sub pages and raise issues.
Something like that?

[adrielp]

@adrielp In the end I'd love to have, not so much in proposal format but as an end product, brief documentation for future generations on why we've chosen Renovate so that every time a new person asks why, we can point them at our reasoning. I think we'd want to have this for each tool we recommend as our 'standard'. It would be great if you are willing to write up something for that.

I'm currently focused on the vuln management side of things, so I haven't thought too much on the format for the supply chain security documentation, but eventually I see something like a high level doc that is just the enumerated list of tools/configuration settings recommended (required?), but it has links to sub pages that explain the why for those who care. Maintainers who just want to follow the recipe can just read the top level doc and execute on each item. Those who want to argue about the merits of a specific item can read the sub pages and raise issues. Something like that?

Yea, that sounds great, and I'd be happy to. Basically, an ADR. Great for context and future reasoning. I think an ADR format for SIG Security would be great in general. But keep it lighter weight than say our OTEP/RFC process. That sound right?

[trask]

many repos are using dependabot, I think that also supports pinning also?

I thought it did, but I'm not finding a clear reference to it in the configuration docs. However, looking through issues and source code, I found the original issue and pull request. It looks like it only does it if it's already been set to the SHA with a comment. If not, it'll use the current version.

ah, found the dependabot issue for the missing feature that we want: dependabot/dependabot-core#7913

[trask]

tested this with renovate, very nice: trask/semantic-conventions#10

[lmolkova]

thanks a lot!

Is there a way we can set some labels on the renovate PRs? We use dependencies and Skip Changelog in semconv to skip changelog check. Would be nice to automate setting the label and skipping the check.

[adrielp]

@lmolkova absolutely. Renovate supports labels out of the box. You can do labels by package grouping, labels specifically for security, and labels for dependencies as a whole. A common set of labels I've found useful are dependencies and renovate for all deps, security for security specific related updates, and major for major dependency updates.