Define design for Renovate usage #15594
Conversation
| ### Fork Mode | ||
|
|
||
| Protecting GitHub repositories in the dotnet organization from direct access by the Renovate tool is crucial. | ||
| Renovate will be used in fork mode, limiting its permissions to forked repositories. |
There was a problem hiding this comment.
Will these repos be long-lived? Where will they exist?
There was a problem hiding this comment.
I read that the permissions/threat model is that Renovate is the same as all the OSS devs contributing on our repos. That would be good to call out explicitly (in a prior section).
There was a problem hiding this comment.
Will these repos be long-lived? Where will they exist?
Yes, once a dotnet repo is forked, the fork will be preserved indefinitely. The fork repo will be owned by the bot account (e.g. https://github.com/dotnet-renovate-bot/dotnet-runtime).
I read that the permissions/threat model is that Renovate is the same as all the OSS devs contributing on our repos. That would be good to call out explicitly (in a prior section).
Good point.
There was a problem hiding this comment.
How will the repos get the latest commits? Will the bot update its main branch before creating its change in a topic branch?
There was a problem hiding this comment.
Yes, the bot handles all of that.
There was a problem hiding this comment.
It would be good to see that covered in the design. It doesn't need to be deep.
There was a problem hiding this comment.
Why do you think this particular aspect belongs in the design? That's very much an implementation detail. And given that there's nothing we need to do to enable it, it seems unnecessary. There's all kinds of questions that could be asked of how Renovate works, but that doesn't mean they need to be called out in the design.
There was a problem hiding this comment.
I wanted to know if renovate can have multiple PRs in-flights from the same repo at once. I assume so but wanted to validate.
| Renovate will be used in fork mode, limiting its permissions to forked repositories. | ||
| This avoids giving write permissions to Renovate on any dotnet repository. | ||
| A GitHub bot account, `dotnet-renovate-bot`, is used to manage the Renovate operations. | ||
| This account has the ability to create forks from dotnet repositories, which will be the source of the head branch for PRs that are created. |
There was a problem hiding this comment.
This text implies but does not explicitly state that the PRs will be created by this bot. That would be good to fix.
| However, Renovate supports a much broader range of [dependency types](https://docs.renovatebot.com/modules/datasource/), most notably Docker and GitHub releases. | ||
| For example, Renovate can automatically generate a PR to update a referenced Docker image when a newer version is available. | ||
|
|
||
| ## Design |
There was a problem hiding this comment.
It would be good to cover a couple intended to scenarios and why they are important.
An important question to address will be the timing model we use. While that's not important to decide at this stage, it is important to discuss so that we validate that we've got a working model.
I'm thinking about dotnet/dotnet-buildtools-prereqs-docker -> dotnet/runtime:
Here are three options:
- New PR per new image available
- New PR per day
- New PR on-demand
For people at all familiar with this repo, it doesn't take long to realize that the first option is going to generate too many PRs. See publish history to grasp why. The middle model seems like a good default. However, it is suprisingly common that we need a new image to unblock runtime. We had one today, with dotnet/dotnet-buildtools-prereqs-docker#1381. We could wait for the "overnight process" to deal with that. However, an on-demand model seems like it would be nice. Perhaps we can wait to prove that it is necessary. We could also write tools to enable manual sha-updating per dotnet/runtime#113185.
I see this thinking as part of the initial design.
|
|
||
| ### Repo Usage | ||
|
|
||
| Arcade provides an Azure DevOps pipeline YAML job template that repositories should utilize when making use of Renovate. |
There was a problem hiding this comment.
Does this exist yet? If so, then link it here?
There was a problem hiding this comment.
No, it doesn't. I purposely wrote it forward-looking so that it would be relevant once it's implemented.
|
I really do like the fact that the bot writes to a fork. |
|
|
||
| ```diff | ||
| -mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-helix-amd64 | ||
| +mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64 |
There was a problem hiding this comment.
given our support matrix, do we actually want upgrades like this in our repos❓
separately, does Renovate handle updating FROM in Dockerfiles themselves❓ I mostly want to avoid someone accidentally merging a Renovate PR that bumps FROM library/debian:bookworm to FROM library/debian:bookworm in the Debian 12 Dockerfile
There was a problem hiding this comment.
given our support matrix, do we actually want upgrades like this in our repos❓
Repo maintainers are free to choose what they want to have updated because they are in control of their configuration. So if they don't want something to be considered for updating by Renovate, they can choose to not have it included. But to answer your question, I would expect that in most cases, yes, you would want to update to target the latest supported version.
separately, does Renovate handle updating
FROMin Dockerfiles themselves❓ I mostly want to avoid someone accidentally merging a Renovate PR that bumpsFROM library/debian:bookwormtoFROM library/debian:bookwormin the Debian 12 Dockerfile
I think you have a typo since you indicated bookworm twice. Did you mean you want to avoid it updating from bookworm to trixie for a Dockerfile specifically meant for Debian 12? Yeah, in that case Renovate allows you to control the versioning level of updates you want. For example, you could limit the updates to minor version only so that it would never update to a new major version. That would cover your scenario, if I'm understanding it right. For example, you could configure it so if you had a tag like debian:12.8, it would update it to debian:12.9 but not debian:13.x.
|
|
||
| ```diff | ||
| -mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64@sha256:b99da50c4cb425e72ee69c2b8c1fdf99e0f71059aee19798e2f9310141ea48fb | ||
| +mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64@sha256:6bb6fef390e6f09a018f385e346b0fe5999d7662acd84ca2655e9a3c3e622b71 |
There was a problem hiding this comment.
I believe dotnet/runtime is considering moving toward this approach from our current floating tags. if that's correct, I can definitely see the value — means PR validation runs before a newer image breaks the world. please confirm
There was a problem hiding this comment.
Yes, exactly. This is described in dotnet/runtime#113455.
| ### Repo Usage | ||
|
|
||
| Arcade provides an Azure DevOps pipeline YAML job template that repositories should utilize when making use of Renovate. | ||
| This template handles the execution of Renovate, ensuring a standardized approach across all repositories. |
There was a problem hiding this comment.
implementation detail but how complex would such a template need to be❓
This design document describes my proposal for how Arcade can provide the use of Renovate by consuming repos. The use of Renovate is an important part of dotnet/dotnet-buildtools-prereqs-docker#1321 which will greatly simplify the process of keeping consuming repos up-to-date with supported images. It be used in other scenarios besides Docker, such as needing to keep up-to-date with 3rd party products which provide releases through GitHub.
The language used in the doc describes things as if they already exist, so it'll continue to be correct and relevant once this is all implemented.
My ask is for the dnceng team to own and manage the bot account. I'm happy to implement everything else.
@mmitche - Please add any other reviewers you think should see this.