Hi,
First of all, thank you for this great tool and for providing it freely for open-source projects :heart:
I'm opening this feature request because the Git submodules updater always bumps to the latest commit of a specific branch. It works perfectly well but, not all projects use a dedicated branch for stable code. This is why I would like to be able to bump to the latest release (git tag) present in a repository. This API call can be used for this purpose.
Thanks for the feedback @SkypLabs.
Hmm, this is an interesting one. I can see the use case, but I can't see an obvious way for Dependabot to detect that that's what you want, since the .gitmodules file doesn't support specifying tags. (Checking whether the existing commit coincides with a tag won't work, either, because that would happen for folks tracking a branch if/when Dependabot updated them to its HEAD right after a release.)
As a result, the only way I can think to support this would be to add a new option stored on the update config (and configured in the Dependabot dashboard). I'm not averse to that - I think we're going to want an option to opt-in to pre-releases at some point, and this could be combined with that.
Without that option, I'm afraid this is going to have to wait, but I'm pretty sure we'll get to it. 馃檪
As a result, the only way I can think to support this would be to add a new option stored on the update config (and configured in the Dependabot dashboard). I'm not averse to that - I think we're going to want an option to opt-in to pre-releases at some point, and this could be combined with that.
It's exactly what I had in mind actually, hence the link to the "Get the latest release" API call I put in my initial message.
Without that option, I'm afraid this is going to have to wait, but I'm pretty sure we'll get to it. :slightly_smiling_face:
Great, thanks!
Super interested in this also! Exactly the same use case. We sometimes use a submodule to vendor/wrap a project for build purposes, but we only want to update the submodule on tags/releases.
Would love to have this too!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.
Negative @stale, please keep this open
Would be wonderful to have this, some repositories are very hard to keep track of without this.
Hello.
Any updates on this one?
Slightly off topic, but is there a way to bump to an older tag (commit) of the submodule?
@greysteil
before the update config gets enhanced with new option to select between pre-release commits and only release commits possibly extending versioning-strategy to gitsubmodules,

one cheap UI convenience to help humans check whether dependabot PRs coincides with a tag would be to add an href to the github tags page in the PR body. Currently, this requires multiple clicks to browse to tags (see https://github.com/orange-cloudfoundry/paas-templates/issues/869#issuecomment-694787430 for current manual steps).
ie. for https://github.com/orange-cloudfoundry/paas-templates-private/pull/278
Bumps [submodules/cf-deployment](https://github.com/cloudfoundry/cf-deployment) fromc7af666toc317ab9
would become
Bumps [submodules/cf-deployment](https://github.com/cloudfoundry/cf-deployment) fromc7af666toc317ab9(unrelated to [tags](https://github.com/cloudfoundry/cf-deployment/tags))
Nice idea! I don't work on Dependabot anymore (I'm working on GitHub's code scanning features nowadays) so I'll leave this for @feelepxyz and the team (although I know they've had their work cut out with scaling to support millions of repos).
@gberche-orange are you checking if the commit corresponds to a tag before merging? So c317ab9 corresponds to v13.19.0?
Not sure it makes sense to add a plain link to tags but maybe highlight the corresponding tag in the commits list if this is what you need?
We're currently busy migrating Dependabot Preview to GitHub so don't have much spare capacity but can review any PRs to dependabot-core if you wanted to submit a fix there.
Thanks @feelepxyz The best user experience would be to support an optin flag such as 'versionning-strategy' to only receive PRs for commits matching tags. Otherwise, you're right, the workaround of indicating in the pr body which commit matches tags is a better alternative. I'll try looking if this could be easily contributed.
Most helpful comment
Negative @stale, please keep this open