Renovate Preset for Bazel Rulesets

[cgrindel]

I have developed a Renovate configuration for Bazel rulesets. The goals of the configuration are as follows.

1. Do not update dependencies defined in the root MODULE.bazel. The idea is that a ruleset should strive to require the lowest viable version of an external dependency so that clients can dictate the version of a dependency to use.
2. Find and update dependencies defined in child workspaces (i.e., in a repository subdirectory). While a ruleset should require the lowest viable version of an external dependency, ensuring that the ruleset works with the most recent version of an external dependency is desirable. Hence, example and test workspaces should be updated to the latest version.

Testing

I have created a Renovate preset with the proposed configuration. I have updated bazel-starlib, rules_swift_package_manager, and rules_swiftformat to use the preset. So far, Renovate is providing the desired updates.

Caveats

1. Renovate does not update development-only dependencies with this configuration. Clients need to update these dependencies manually.
2. Without additional configuration, all example and test workspaces will have their external dependencies updated to the latest version. Having at least one example/test workspace may be desirable to use the lowest viable version of each external dependency.

Next Steps

Once we have a consensus on the recommended ruleset configuration, I propose defining a Renovate preset and advertising it to rules authors. The question is, where should it live? I think that there are two options.

1. A repository under bazel-contrib called renovate_presets or renovate-presets.
2. Create a directory in the rules-template repository.

I think that a dedicated repository makes a little more sense, as we want to encourage clients to use the preset instead of copying the configuration. Thoughts?

Please let me know what you think of the configuration and how it should be advertised.

[aherrmann]

1. Do not update dependencies defined in the root `MODULE.bazel`. [...] a ruleset should strive to require the lowest viable version of an external dependency [...].
2. Find and update dependencies defined in child workspaces [...] ensuring that the ruleset works with the most recent version of an external dependency [...].

I agree with the intention. Can the strategy be made configurable? Considering rules_nixpkgs, for example, the repository contains multiple repositories that are user facing (./core, ./toolchains/cc, ./toolchains/go, ...) as well as multiple testing repositories (./testing/core, ./testing/cc, ..., ./examples/cc-template, ...). So, the assumption that only the top-level module is user-facing, and should therefore use the lowest viable dependency versions, and all other modules are test modules, and should therefore use the most recent dependency versions, is not generally valid.

[cgrindel]

That is a good point. Repositories with multiple client-facing workspaces can list the packages to disable or tell Renovate to ignore entire sections of the repository. The rules_nixpkgs should be able to achieve the desired results with the following configuration:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "github>cgrindel/renovate_presets:ruleset_base"
  ],
  "ignorePaths": [
    "**/testing/**"
  ],
  "packageRules": [
    {
      "matchFiles": [
        "core/MODULE.bazel",
        "toolchains/cc/MODULE.bazel",
        "toolchains/go/MODULE.bazel"
      ],
      "enabled": false
    }
  ]
}

Of course, if no workspaces should be processed for updates, one can just disable Renovate for the repository.

@aherrmann For rules_nixpkgs are there any workspaces that should be managed by Renovate? For instance, should example workspaces be kept up-to-date?

[aherrmann]

Thanks for clarifying @cgrindel! Good to hear that this is supported.

For rules_nixpkgs are there any workspaces that should be managed by Renovate? For instance, should example workspaces be kept up-to-date?

We haven't completed the bzlmod migration, yet. And we're not currently using renovate-bot. So, there is still some work to do before we can get there. But, the strategy you lay out in #82 (comment) sounds reasonable to me. Following that, I think we'd want to keep the testing and examples workspaces up-to-date. cc @benradf.

[cgrindel]

@brentleyjones I believe you have thoughts on how dependencies for rulesets should be managed. Do the goals listed above satisfy the requirements as you see them?

[brentleyjones]

Yes. The key thing for me is the first point, so thank you for that.

[cgrindel]

This was discussed at the Bazel Rules Author SIG meeting yesterday. There were no comments about this topic.

I have not heard from anyone that they would use a Renovate preset defined in a bazel-contrib repository. So, it may not be worth maintaining a repository for it.

For posterity, the Renovate configuration that disables updates in the root and allows updates in sub-directories is below:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    ":dependencyDashboard",
    ":semanticPrefixFixDepsChoreOthers",
    "group:monorepos",
    "group:recommended",
    "replacements:all",
    "workarounds:all"
  ],
  "packageRules": [
    {
      "matchFiles": ["MODULE.bazel"],
      "enabled": false
    }
  ]
}

[jsharpe]

For what its worth https://github.com/bazel-contrib/rules_cuda/pull/118/files is how we fixed this up in rules_cuda before you posted this preset.
For me the value of having this setup really is in the rules_template repo so that new rulesets are defaulted into this behaviour?
We should probably also encode in rules_template the min version examples structure that you described on the call so that new rules authors can follow this pattern.

[cgrindel]

That is a good point. I was so focused on setting up a preset that I failed to recognize the better solution. I'll put up a PR with the config.

[cgrindel]

bazel-contrib/rules-template#84