Dependabot docs - #617
Conversation
britt-allen
left a comment
britt-allen
left a comment
There was a problem hiding this comment.
Thanks Ian! This is thoughtful work. I just did a readability pass with Hemingway.
| ``` | ||
| 1. Open a pull request against `main` with your branch in GitHub. Once CI passes, | ||
| feel free to merge. We don't need to rely on code review for security patches. | ||
|
|
There was a problem hiding this comment.
I think adding a step to confirm the Dependabot alert is resolved after the updated lockfile is merged might help?
|
dbt failure might be related to this |
I kicked the build and it succeeded. Looked like a transient Snowflake error to me 🤷 |
|
|
||
| Automated security scans can reduce vulnerabilities in our software dependencies. | ||
|
|
||
| ## Decisions |
There was a problem hiding this comment.
for clarity -- these are decisions we've made, or decisions still up for discussion?
There was a problem hiding this comment.
Let's talk about it! I didn't hear much objection to them when I proposed them, but I wouldn't consider these "decisions made" until we have some consensus and they are merged!
There was a problem hiding this comment.
My take so far:
- Group pull requests -- I don't know if we have to protect against alarm fatigue if we're also implementing / enforcing a teamwide process for addressing them. Could go either way on this
- Dependency cooldowns -- I think we should do this!
- Avoid specific Dependabot configuration -- Why is it simpler to avoid configurations (assuming we would then apply all config as a default to our template? Is it because we have so many package ecosystems to monitor and it's not worth defining config for each one (as far as we know right now)?
There was a problem hiding this comment.
Avoid specific Dependabot configuration -- Why is it simpler to avoid configurations (assuming we would then apply all config as a default to our template? Is it because we have so many package ecosystems to monitor and it's not worth defining config for each one (as far as we know right now)?
Basically, because while propagating changes from our template to downstream projects works, it's kind of annoying (somewhat evidenced by how infrequently we do it). So my motivation here was to try the simplest thing that could possibly work (no configuration) first, and then re-evaluate if we need to.
There was a problem hiding this comment.
@summer-mothwood are you okay with the proposed process as it sits?
4 participants
Proposed process for handling dependabot security updates