git-submodules: renovate updates to branch if it matches semver pattern

[nejch]

What would you like help with?

I think I found a bug

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

When using the semver approach for branch in .gitmodules as documented, renovate will update using tags.

However if the target repository uses tag-like branches, renovate seems to pick them up as tags for new versions and updates to the HEAD of those, rather than only for tags.

Example repo using pre-release branches (e.g. 4.10.0 => v4.10.0 tag after release):
https://github.com/wazuh/wazuh-kubernetes/branches (at the time of writing, a 4.1.0 branch exists)
https://github.com/wazuh/wazuh-kubernetes/tags (at the time of writing, v4.9.0 is the latest tag)

Reproduction repo:
https://github.com/nejch/renovate-repro-git-semver

Reproduction repo PR with update to branch:
https://github.com/nejch/renovate-repro-git-semver/pull/1/files

Logs (if relevant)

No response

[github-actions[bot]]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

If you need help with running renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[rarkins]

@nejch please see the template repo for an example README structure we ask for in reproductions. No need to recreate it but please create a readme using those headings

[rarkins]

Also a little tip for clarity. It's unclear from the description here either what the bug is.

You make two statements:

When using the semver approach for branch in .gitmodules as documented, renovate will update using tags.

However if the target repository uses tag-like branches, renovate seems to pick them up as tags for new versions and updates to the HEAD of those, rather than only for tags.

Do both statements above reflect Renovate's current behavior? But the second statement is what you consider to be buggy behavior?

This is why we ask for "I expect X, but what I see is Y" so that it's easier to understand

[nejch]

Sorry, wanted to provide the context for the specific setup there as it's a relatively new feature hence the first sentence. I've added a README to the repro project now, should be clearer now hopefully. It's been a while since I last opened an issue here and I totally missed the repro instructions!

[rarkins]

I'm not sure there's a solution here. Even less sure that it's a bug.

Git submodules natively does not have a mechanism for tracking tags - only branches. Because we know that some users would like to track tags, Renovate supports that doing the "branch =" setting, even though technically it's an incorrect of this field for git submodules.

So if you have something like "branch = v1.0.0" and that's a tag, there's no annotation here saying "hey Renovate, this is actually a tag, not a branch". It should work with either approach. Next, I don't think it's obvious that every Renovate user would want to use only tags. Having branches and tags named similar (e.g. semver) sounds like an undesirable practice because if you have a branch named x.y.z then you can't have a tag with that same x.y.z too.

Anything I'm misunderstanding or missing?

[nejch]

Definitely agree this feature essentially needs to misuse the branch submodule config, but it's a very convenient feature to work around git not natively tracking tags in submodules so I'm happy to see it 🙂. The docs imply this is meant specifically for tags (https://docs.renovatebot.com/modules/manager/git-submodules/#updating-to-specific-tag-values), hence why I marked it as a bug but maybe just a warning in the docs would be enough.

Having branches and tags named similar (e.g. semver) sounds like an undesirable practice because if you have a branch named x.y.z then you can't have a tag with that same x.y.z too.

I agree completely, and I was also surprised when I saw it, but this happened in an external dependency (https://github.com/wazuh/wazuh-kubernetes) that I don't have control over.

---

What I could imagine might work is something like a tagsOnly: true config option, that would then distinguish between refs/heads/* and refs/tags/* when fetching the refs via ls-remote. Not sure if that makes sense.

[rarkins]

Docs fix in #31515

There's no easy fix or feature to change this behavior

[nejch]

Thanks!

[nejch]

For any future readers: if the target repo has a slight difference in branch/tag naming (e.g. tags are v-prefixed but not branches, as is the case in the example repo above), you can potentially force renovate to only update tags using a pattern with matchNewValue.