git-submodules: option to restrict updates to tags only

[catostrophe]

Tell us more.

Summary

Allow the git-submodules manager to be configured so that only tags are considered as candidate updates, ignoring branches — including branches whose names happen to look like versions.

Current behaviour

The git-submodules manager is hardcoded to the git-refs datasource:

• lib/modules/manager/git-submodules/index.ts — supportedDatasources = [GitRefsDatasource.id]
• lib/modules/manager/git-submodules/extract.ts — emits datasource: GitRefsDatasource.id

git-refs returns both heads (branches) and tags:

// lib/modules/datasource/git-refs/index.ts
rawRefs.filter((ref) => ref.type === 'tags' || ref.type === 'heads')

There is no manager option to limit the lookup to tags. The readme.md even states this is by design:

Renovate will then automatically update this version to the latest Git branch or tag which satisfies your versioning scheme.

A separate git-tags datasource that filters to type === 'tags' already exists (lib/modules/datasource/git-tags/index.ts), but the manager doesn't use it.

Problem

When a submodule's upstream publishes both:

• release tags like v1.2.3, and
• maintenance/release branches with version-like names (e.g. 2.x, release/1.2, or even v1.2.3 reused as a branch),

Renovate may surface a branch as a "newer version" of the submodule, which is not what we want. We track releases by tag, and branches that happen to be named like versions should be ignored.

Workarounds today are imperfect:

• allowedVersions filters by name, so a branch named like a version still passes.
• ignoreDeps requires per-submodule maintenance and disables updates entirely.

Proposed change

Add a manager option to control which ref types are considered. A couple of possible shapes:

1. New manager option on git-submodules, e.g.:

   {
     "git-submodules": {
       "refType": "tags"
     }
   }

   Valid values: "tags" | "branches" | "any" (default: "any" for back-compat).

   When set to "tags", the manager would emit datasource: 'git-tags' (or pass a filter down to git-refs) so that only refs/tags/* are considered.

2. Alternatively, expose git-tags as an additional supported datasource for the manager and let users opt in via packageRules (matchDatasources / overrides). Less discoverable, but more flexible.

Option 1 feels simplest and matches existing patterns (manager-level defaults overridable per package rule).

Back-compat

Default would remain the current behaviour (both tags and heads), so no existing setups change.

Willing to implement

Yes — happy to send a PR once the approach is approved. I'd lean toward option 1 (refType on the manager config), defaulting to "any".

[catostrophe]

@viceice sorry for pinging you directly. could you review the proposal? I would like to implement it.

[viceice]

have you tried to override the datasource?

https://docs.renovatebot.com/configuration-options/#packagerulesoverridedatasource

[catostrophe]

Thanks. It worked. It was not trivial to figure it out without your help.

[Matze1224]

Hi, tried the following without success (renovate still creates MRs for not tagged commits). I agree with catostrophe that this is difficult to find nor documented.

This is my project ``renovate.json`:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "git-submodules": {
    "enabled": true
  },
  "packageRules": [
    {
      "matchManagers": ["git-submodules"],
      "overrideDatasource": "git-tags"
    }
  ]
}

Did I something wrong?