问题标签 [dependabot]

查看一个人拥有的所有存储库中的所有打开的拉取请求可能很有用，而不仅仅是一个人创作的那些（在搜索栏上突出显示）。

一个例子：我已经为几十个存储库激活了自动安全更新。在我的帐户中，现在有很多 PR 是由dependabot撰写的。我希望列出所有这些非常相似的 PR，以便我可以方便地审查和（大部分）批准它们。我也想要非依赖机器人编写的 PR，因为我知道在某些情况下维护人员自愿在仔细审查的情况下进行更新。在大多数情况下，我更喜欢这些 PR，但仍希望对其进行审查。

我为我的 GitHub 项目启用了 Dependabot：https ://github.com/t1/deployer

有一段时间，它打开了无法向 JCenter 进行身份验证的问题，例如https://github.com/t1/deployer/issues/163

我不想提供我的凭据！它为什么要这样做？我不记得将它配置为使用 JCenter 做任何事情。我还没有找到任何配置选项，也没有在 Google 上找到任何有用的东西。

我们最近从 切换greenkeeper到dependabot进行依赖项检查，我们注意到dependabot打开的 PR 只改变了package-lock.json原样package.json。

另一方面，greenkeeper, 正在提交对两个文件的更改。

到底是怎么回事？这是正常的还是我们错过了设置中的某些内容？

因此，当 Dependabot 运行并创建带有库更新的 PR 时，它会更新 package.json 和 package-lock.json 中的库版本，但是是否有任何我可能丢失的配置，即在dependabot 的每个 PR 中更新包.json 版本，例如：

当前版本是版本：0.0.1

在运行dependabot并为某些库更新创建相应的PR后，有没有办法增加package.json（带有semver）的数量，如下所示：

更新后的版本应该是：版本：0.0.2

根据文档，有现有的选项

但是这两个选项都用于更新依赖项或devDependencies中使用的库的版本。

这是我的dependabot 配置，有没有办法排除主要版本更新而只有次要、补丁和安全更新？如果是这样，我需要改变什么？

如果启用 Dependabot 以自动增加依赖项并创建对“主”的拉取请求，如果 Dependabot 的分支通过 Azure Devops 构建管道，这些拉取请求如何自动化以便自动批准和合并？

我在 Github 上有一个 Laravel 项目，dependabot 电子邮件警告我 Laravel 的 symfony/http-foundation 依赖存在安全漏洞（该漏洞的版本 >= 3.0.0 和 < 3.4.26。

有没有办法确定使用此依赖 >= 3.4.26 版本的 Laravel 最低版本是什么。

我没有时间迁移到最新版本，所以我希望迁移到没有此问题的 Laravel 最低版本。

谢谢

我的一个 github 页面（https://github.com/akademie-oeffentliches-gesundheitswesen/krisenmanagment ）从 github 收到了一个依赖机器人警报（CVE-2020-14001 漏洞版本：< 2.3.0 修补版本：2.3.0 ） . 该警报应该在 gemfile.lock 中。但是我在这个存储库中没有那个文件或 gemfile，因为我切换到了一个远程主题。

我有几个其他存储库可以修复此错误消息，但在这种情况下，我不知道从哪里开始。

package-lock.json为上次运行时安装的所有依赖项和传递依赖项存储一组精确版本npm update。我们鼓励您重新提交package-lock.json您的回购协议。

package-lock.json我能找到的唯一真正的消费者是npm ci，它精确地再现了定义的状态，package-lock.json这样您就可以确定您在与上次编写的开发机器上相同的依赖项上运行 CI package-lock.json。

另一件事package-lock.json似乎用于产生大量的安全警告。我已经对我提交的package-lock.json文件进行了 Github 的 Dependabot PR-ing 更改，并抱怨我package-lock.json是它“发现”其他无法为我自动修复的漏洞的地方。我怀疑这些无法修复的问题是 my 或依赖项中的问题package.json，由排除有问题模块的固定版本的最大版本要求引起，但这不是 Dependabot 所说的：

如果package-lock.json仅由 使用npm ci，那么对那里的包的过时且易受攻击的版本的引用如何在我的 CI 系统之外的任何地方创建漏洞？实际安装软件包的人不会使用package.json来解决依赖关系，从而在所有漏洞可用时自动修复它们（除非我自己有一个令人讨厌的最大版本限制）？这些对我的 repo 的 PR 真的只是建议我和我的所有用户/合作者npm update在我们的机器上运行吗？如果是这样，是什么让 Dependabot 作者通过拉取请求来做到这一点？

如果我package-lock.json从源代码控制中删除，这是否会正确解决package-lock.json-indiced 漏洞（因为该文件不再存在以欺骗某人安装我的依赖项的旧易受攻击版本）？或者它只会使漏洞扫描程序无法扫描我的存储库（即他们是否依赖package-lock.json而不是自己解决依赖关系package.json）并使我不知道何时需要npm update？

所以我使用 githubdependabot v2 并有这个配置：

我希望它在我进行推送/更改时检查更新。我该怎么做呢？