-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ci] Add dependabot configuration for updating git submodules #6565
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this!
I'm generally very supportive of doing this, but I have a question... what tells dependabot that there's a new version?
Things I would not support triggering on:
- new commit on default branch
Things I would support triggering on:
- new tag pushed
stable
or similar tag ref updated (as @StrikerRUS noted in List of dependencies that should be updated from time to time #3763)- new release cut in source code management (GitHub / GitLab)
The docs at https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file have 0 details on package-ecosystem: gitsubmodule
, and I haven't yet found an answer to this in my searching around the internet.
I found dependabot/dependabot-core#1639 which seems to suggest that it is based on latest commit, but not sure if that just is a stale issue that hasn't been closed yet.
It does some like maybe renovate supports watching for new
git` tags, basedo n the existence of https://docs.renovatebot.com/modules/datasource/git-tags/. Maybe we could try that?
Well why not just update to the latest commit?
I'm mostly just repeating things @msarahan taught me here. In general a new non-tagged commit is not the same as a "release", because:
- releases tend to have been put through some additional, more expensive testing that other commits have not
- releases may include changes to documentation or configuration which are only pushed to source control right before release time
- like setting CMake build type to
Release
to remove debugging symbols or assertions - like adding "added/removed in version
{version}
" things to docs and log messages
- like setting CMake build type to
I like this automatization! Thanks for working on it @borchero ! Also I'm totally agree with @jameslamb that we should have more granular control over updates compared to simple "update on every commit". |
@borchero it's been a couple months since this PR was opened and @StrikerRUS and I left feedback... can you please either come back to work on this or let us know you aren't interested any more and close it? |
Sorry I left this open for so long @jameslamb 😬 to the best of my knowledge, dependabot does, indeed, not support updating only to releases. I have not yet used renovate anywhere so I'd need to spend a little more time to investigate how to set this up. Regardless, I am closing this PR for now 😅 |
No problem, thanks for coming back to it! Happy to review another PR if you return to this in the future. |
Implementation of this comment.
In contrast to CI updates, I refrained from grouping together updates of git submodules to isolate potential issues to individual dependencies. If this creates too many PRs, we can, of course, change this behavior at a later point.