|
| 1 | +# Renovate Dependency Update Tool |
| 2 | + |
| 3 | +## Introduction |
| 4 | + |
| 5 | +This document outlines the integration of [Renovate](https://github.com/renovatebot/renovate) into Arcade to automate dependency updates. |
| 6 | +Renovate is an automated dependency update tool that generates PRs for updating dependencies from a wide variety of sources. |
| 7 | + |
| 8 | +Renovate is similar to Dependabot in its purpose. |
| 9 | +Dependabot should be used when possible. |
| 10 | +However, Renovate supports a much broader range of [dependency types](https://docs.renovatebot.com/modules/datasource/), most notably Docker and GitHub releases. |
| 11 | +For example, Renovate can automatically generate a PR to update a referenced Docker image when a newer version is available. |
| 12 | + |
| 13 | +### Example Scenarios |
| 14 | + |
| 15 | +Here are two scenarios demonstrating the usefulness of Renovate automatically making dependency updates: |
| 16 | + |
| 17 | +#### Container Tags |
| 18 | + |
| 19 | +Repos that reference container tags from the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo need to maintain those tags to ensure they are supported. |
| 20 | + |
| 21 | +This can be as simple as automatically updating to a new major version of Linux distro: |
| 22 | + |
| 23 | +```diff |
| 24 | +-mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-helix-amd64 |
| 25 | ++mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64 |
| 26 | +``` |
| 27 | + |
| 28 | +Or automatically pinning to the latest version of a tag by it's digest value: |
| 29 | + |
| 30 | +```diff |
| 31 | +-mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64@sha256:b99da50c4cb425e72ee69c2b8c1fdf99e0f71059aee19798e2f9310141ea48fb |
| 32 | ++mcr.microsoft.com/dotnet-buildtools/prereqs:debian-12-helix-amd64@sha256:6bb6fef390e6f09a018f385e346b0fe5999d7662acd84ca2655e9a3c3e622b71 |
| 33 | +``` |
| 34 | + |
| 35 | +Renovate can detect when these new container images are available and submit PRs to update sources accordingly. |
| 36 | + |
| 37 | +Related issue: [Automatically update image references in consuming repos (#1321)](https://github.com/dotnet/dotnet-buildtools-prereqs-docker/issues/1321) |
| 38 | + |
| 39 | +#### GitHub Release |
| 40 | + |
| 41 | +There are many cases where a version of OSS published via GitHub releases is being referenced by a .NET repository. |
| 42 | +Those versions can be kept updated automatically as new releases occur. |
| 43 | + |
| 44 | +For example, there are Dockerfiles in the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo which reference the LLVM version that can be maintained by having Renovate automatically check for new [LLVM releases](https://github.com/llvm/llvm-project/releases). |
| 45 | + |
| 46 | +```diff |
| 47 | +-LLVM_VERSION=19.1.7 |
| 48 | ++LLVM_VERSION=20.1.0 |
| 49 | +``` |
| 50 | + |
| 51 | +## Design |
| 52 | + |
| 53 | +### Fork Mode |
| 54 | + |
| 55 | +Protecting GitHub repositories in the dotnet organization from direct access by the Renovate tool is crucial. |
| 56 | +Renovate will be used in fork mode, limiting its permissions to forked repositories. |
| 57 | +This avoids giving write permissions to Renovate on any dotnet repository. |
| 58 | +This means that Renovate acts as though it's any other outside contributor, not requiring any special permissions in the dotnet organization or repositories. |
| 59 | + |
| 60 | +A GitHub bot account, `dotnet-renovate-bot`, is used to manage the Renovate operations. |
| 61 | +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. |
| 62 | +The PRs generated by Renovate will be done using this bot account. |
| 63 | +Renovate also handles synchronization from the upstream branch automatically. |
| 64 | +GitHub scopes required by this account: `repo`, `workflow`. |
| 65 | + |
| 66 | +### Repo Usage |
| 67 | + |
| 68 | +Arcade provides an Azure DevOps pipeline YAML job template that repositories should utilize when making use of Renovate. |
| 69 | +This template handles the execution of Renovate, ensuring a standardized approach across all repositories. |
| 70 | +Repositories wishing to make use of Renovate can reference this template from a pipeline YAML file, setting the schedule trigger as desired. |
| 71 | +Consuming repositories are responsible for providing their own [Renovate configuration file](https://docs.renovatebot.com/configuration-options/) that describes which dependencies should be updated. |
| 72 | + |
| 73 | +Repositories are in control of how often Renovate will run via the pipeline schedule trigger (once a day, once a week, etc). |
| 74 | +Typically, a pipeline would be configured to update all dependencies at once in which case all dependencies are described in one Renovate config file. |
| 75 | +But in some cases, it may be desired to have certain dependencies updated on a different schedule than others. |
| 76 | +In that case, the repo maintainer would define multiple pipelines with those separate schedules, all configured to run Renovate. |
| 77 | +Importantly, each of those pipelines would need to reference a separate Renovate config file which defines the scope of the updates that will be targeted. |
| 78 | +Lastly, a maintainer is free to manually run the pipeline if an expected update is needed right away. |
| 79 | + |
| 80 | +## Renovate Configuration Patterns |
| 81 | + |
| 82 | +TBD |
0 commit comments