-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
build: Set up Dependabot for go security updates #35499
Conversation
@@ -1,5 +1,15 @@ | |||
version: 2 | |||
updates: | |||
- package-ecosystem: gomod | |||
directory: / |
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.
I know you mentioned backends are tricky but is the intention here to also exclude them from the security update PRs, or would this still imply recursive scan, i.e. would we receive security updates for those as well? for example https://github.com/hashicorp/terraform/blob/main/internal/backend/remote-state/azure/go.mod
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.
That's a great question -- you all know more about Go dependencies than I do, and if you don't know then we may just have to try this out and see what happens. My rough understanding (if it works like it does for JS/NPM), then the directory: /
here means it's responsible only for updating the top-level go.mod
file and not any of the ones in subdirectories (i.e. the backends) unless a change to the top-level go.mod
file requires a change in the subdirectories. That's how it works in JS but I don't know if there are any differences in the behavior for Go.
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.
Our repo pretty much always requires changes to all module directories, which is handled manually via our make syncdeps
command. We can't exclude backends, because their go.mod
files will immediately be out of sync. I don't know if dependabot can handle that, or if we ned to add a followup command to clean up after the update.
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.
Interesting, yeah, I think in that case we'll just have to merge this and see what happens, and if additional steps are needed then that probably requires the creation of a custom workflow that runs additional commands based on the Dependabot PR.
e5d734d
to
c94895e
Compare
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This sets up Dependabot to automatically create PRs for Go dependencies with security vulnerabilities. The trick here is the
open-pull-requests-limit: 0
setting, which is essentially the part that says "don't have Dependabot create PRs for regular dependency upgrades, only for security issues". Theschedule.interval: daily
ensures that once a security vulnerability is flagged and a dependency upgrade is available that solves the issue, Dependabot will create a new PR within 24 hours. That seems appropriate for security issues.Eventually we'd like to see if we can scale up to more regular (non-security) dependency upgrades using Dependabot, but given the concern about the maintenance of backends, let's start here first and see how it goes.