Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

borchero
Copy link
Collaborator

@borchero borchero commented Jul 22, 2024

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.

Copy link
Collaborator

@jameslamb jameslamb left a 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:

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

@StrikerRUS
Copy link
Collaborator

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".

@jameslamb
Copy link
Collaborator

@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?

@borchero
Copy link
Collaborator Author

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 😅

@borchero borchero closed this Oct 14, 2024
@borchero borchero deleted the dependabot-submodule branch October 14, 2024 21:13
@jameslamb
Copy link
Collaborator

No problem, thanks for coming back to it! Happy to review another PR if you return to this in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants