Update submodules using tags

[DanySK]

Hi, is there a way to tell renovate to update the git submodules only when a new tag gets released?
Although I fixed the version for the submodule to a specific tag initially, renovate seems to be willing to keep me up to date with master, see these pull requests

Should I maybe configure something into the .gitmodules file? It is currently:

[submodule "src/main/hugo/themes/hugo-theme-relearn"]
	path = src/main/hugo/themes/hugo-theme-relearn
	url = git@github.com:McShelby/hugo-theme-relearn.git

[rarkins]

What does the packageFiles with updates entry for these submodules look like?

[reitzig]

Side question: Why not just use Git's magic? That would, at least, be what I as a user would expect Renovat to do: behave as Git does.
Do you want avoid running git submodule update --init? 🤔

That said, I couldn't find any "easy" reference to a ref name. The docs say:

[git submodule status] print[s] the SHA-1 of the currently checked out commit for each submodule, along with the submodule path and the output of git describe for the SHA-1.

So the "magic" is whatever git describe does. It definitely sounds like the SHA1 is the truth.

I see mention made of the --branch option resp. .branch key but I don't know how that behaves.

That all said: I think git describe is good enough for Renovate. As far as I can tell as a user, Renovate already does magic for determining all tags and their version-ordering; it seems feasible to order (all) tags associated with the SHA1 that's checked out, and compare the "largest" one with what the datasource has scrounged up.

User intent is what may be tricky: did they check out a branch (-> Renovate should ignore it), a tag (-> propose updates), or is it even headless (-> ignore)?
As an opt-in feature, I'd be totally fine with Renovate assuming I checked out a tag, if there are any associated with the checked out rev. I can always reject the PR, after all. (And if I configure automerge, I hopefully know what I'm doing. ;) )

[rarkins]

I could not reproduce the output from @andrewpollock earlier. e.g. I get:

$ git submodule status osv/osv-schema
-c37661d75a28fc759000f863da904f9a2caebac3 osv/osv-schema

And not:

$ git submodule status osv/osv-schema
 c37661d75a28fc759000f863da904f9a2caebac3 osv/osv-schema (v1.6.3)

which includes the tag.

I do not see any evidence of git describe output and can't get it to work on its own:

$ git describe c37661d75a28fc759000f863da904f9a2caebac3
fatal: c37661d75a28fc759000f863da904f9a2caebac3 is neither a commit nor blob

I suspect that this failure is because it's a commit on the submodule repository and git describe works only on the present repository.

BTW I would also like to note that https://git-scm.com/docs/git-submodule does not include the word "tag". Pinning a submodule to a branch seems supported, but not tag.

Then the question is: can Renovate reliably fuzzy guess the tag based on the SHA? Or should we see if there's a way to "annotate" the .gitmodules similarly to how we support annotated GitHub Actions with tags/commits?

[rarkins]

If we go with the "proprietary annotation" approach, this quick test did seem to work:

16:55 $ git submodule init
Submodule 'docker/worker/osv-test' (https://github.com/oliverchang/osv-test.git) registered for path 'docker/worker/osv-test'
Submodule 'gcp/api/googleapis' (https://github.com/googleapis/googleapis) registered for path 'gcp/api/googleapis'
Submodule 'osv-schema' (https://github.com/ossf/osv-schema.git) registered for path 'osv/osv-schema'
✔ /tmp/clone/osv.dev [master|✚ 1]
16:56 $ git diff
diff --git a/.gitmodules b/.gitmodules
index 9f00421..7009eed 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -7,3 +7,5 @@
 [submodule "osv-schema"]
        path = osv/osv-schema
        url = https://github.com/ossf/osv-schema.git
+       tag = v1.6.3
+

[rarkins]

If I have a clone of the submodule itself, then git tag --points-at will list all tags. e.g. in this case there's only one

✔ /tmp/clone/osv-schema [main|✔]
17:17 $ git tag --points-at c37661d75a28fc759000f863da904f9a2caebac3
v1.6.3

[reitzig]

I suspect that this failure is because it's a commit on the submodule repository and git describe works only on the present repository.

Yeah, I guess you'd have to cd into the submodule directory (after git submodule update --init).