There are tons of options to configure. The defaults are handy for smaller projects, but they are clearly spammy for larger ones like this.
https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates <https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates> -- Matt Sicker > On Dec 30, 2021, at 16:48, Rob Tompkins <chtom...@gmail.com> wrote: > > > >> On Dec 30, 2021, at 5:37 PM, sebb <seb...@gmail.com >> <mailto:seb...@gmail.com>> wrote: >> >> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins <chtom...@gmail.com >> <mailto:chtom...@gmail.com>> wrote: >>> >>> Guys. The fundamental argument underpinng all this is whether it’s better >>> to have robot eyes on the code and human eyes on the code. Stop arguing one >>> side or the other. We need to find a way to do both successfully. >> >> The issue is *not* about robot or no robot. >> >> It is about this particular robot that causes so much noise. > > Yes! That’s right so we need to figure out how to use the robot correctly! > >> >>> >>> >>>>> On Dec 29, 2021, at 1:57 PM, Phil Steitz <phil.ste...@gmail.com >>>>> <mailto:phil.ste...@gmail.com>> wrote: >>>> >>>> >>>> >>>>> On 12/29/21 8:43 AM, sebb wrote: >>>>>> On Wed, 29 Dec 2021 at 14:53, Gary Gregory <garydgreg...@gmail.com >>>>>> <mailto:garydgreg...@gmail.com>> wrote: >>>>>>> On Wed, Dec 29, 2021 at 9:42 AM sebb <seb...@gmail.com >>>>>>> <mailto:seb...@gmail.com>> wrote: >>>>>> >>>>>>> On Wed, 29 Dec 2021 at 14:18, Gary Gregory <garydgreg...@gmail.com >>>>>>> <mailto:garydgreg...@gmail.com>> wrote: >>>>>>>> On Wed, Dec 29, 2021 at 9:07 AM sebb <seb...@gmail.com >>>>>>>> <mailto:seb...@gmail.com>> wrote: >>>>>>>> >>>>>>>>> On Wed, 29 Dec 2021 at 13:54, Gary Gregory <garydgreg...@gmail.com >>>>>>>>> <mailto:garydgreg...@gmail.com>> >>>>>>> wrote: >>>>>>>>>> One critical feature is that dependabot does all the builds for you >>>>>>> on >>>>>>>>>> GitHub Actions, this is an enormous time and resource saver! >>>>>>>>> Not at all. >>>>>>>>> Just the reverse. >>>>>>>>> >>>>>>>>> It does NOT save resources, because it runs builds for updates that >>>>>>>>> are not necessary at that point in time (or ever, in some cases). >>>>>>>>> >>>>>>>>> Nor does it same time, because the the noise that it generates. >>>>>>>>> >>>>>>>>> >>>>>>>>> Please stop pretending that Dependabot does things it does not (and >>>>>>>>> likely cannot) do. >>>>>>>>> >>>>>>>> Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV. >>>>>>>> It's as simple as I stated: >>>>>>>> >>>>>>>> If Dependabot detects that a new version of a dependency is available, >>>>>>>> creates a branch, runs a build, tells me the result and I have a PR I >>>>>>>> can >>>>>>>> merge, *that is all work and time *I* do not have to do manually! Why >>>>>>>> is >>>>>>>> that so hard to understand?* >>>>>>> Of course I understand that. >>>>>>> >>>>>> Phew! :-) >>>>>> >>>>>>> However, just because a new version is available does NOT mean that it >>>>>>> has to be updated there and then. >>>>>>> Sometimes it never needs to be updated. >>>>>>> >>>>>> You can't know if you need to make a decision unless someone asks you to >>>>>> make it. I don't know out of thin air that a new version is available. >>>>> You can be pro-active and do a dependency check yourself. >>>>> And you can look out for security bulletins. >>>>> >>>>> That's what we used to do. >>>>> >>>>>>> Changes to dependencies occur much more frequently than component >>>>>>> releases. >>>>>>> So often there will be several mails for the same dependency. >>>>>>> >>>>>>> In the past, the approach was to check for new (and useful) updates >>>>>>> shortly before a release. >>>>>>> >>>>>> That must have been before my time and it seems like a horrible idea: The >>>>>> software is stable after a few months of activity and it's time to make a >>>>>> release, so the day before a release, you change all the dependencies, >>>>>> and >>>>>> cross your fingers? Yikes! >>>>> That is NOT what I said. >>>>> >>>>> Obviously one would start working on version updates some time before >>>>> the release. >>>>> Days or weeks rather than months or years. >>>>> >>>>>>> Generally all the versions would be updated at the same time, instead >>>>>>> of individually. >>>>>>> >>>>>> Not here, if update 10 dependencies and a build fails, then what? I go >>>>>> back >>>>>> to square one and update each, one at a time, until I find the culprit, >>>>>> which to me is a waste of time. BTW, 10 dependencies is not unreasonable >>>>>> for components like VFS, Configuration, and others. >>>>> Well yes, but how likely is there to be a failure in such circumstances? >>>>> >>>>> If the build does not fail, you have saved the noise from at least 9 >>>>> updates which are generally 3 emails per update. >>>>> >>>>> If it does fail, you will have wasted 2 cycles: the original commit of >>>>> 10, and the revert. And only 2 emails. >>>> >>>> +1 and you will get many thanks from those trying to follow commits and >>>> better review of the actual commits. It seems badly broken to me that in >>>> order to effectively review commits to the commons components that I watch >>>> I have to write filters to ignore most of them. The damage from making it >>>> harder to review commits is far greater than the benefit this thing >>>> provides. Actual code commits are where bugs and vulnerabilities get >>>> introduced. Just like mixing formatting changes with functional code >>>> changes is a bad practice, spamming commits@ with a bunch of auto-branch >>>> creations is bad as it dilutes eyeballs, which are the most important >>>> community resource that we have in ensuring code quality and security. >>>> >>>> Phil >>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> On Wed, Dec 29, 2021, 08:51 Rob Tompkins <chtom...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau < >>>>>>>>> rmannibu...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> @Rob: dependabot is mainly about dependencies upgrades and it is >>>>>>>>> also >>>>>>>>>>> why >>>>>>>>>>>> it is so chatty and has so much false positives. >>>>>>>>>>> Yes, I am well aware. But I do not see how a robot telling you to >>>>>>>>> simply >>>>>>>>>>> upgrade is a problem? >>>>>>>>>>> >>>>>>>>>>> Maybe I’m missing something but my impression is that’s what >>>>>>> dependabot >>>>>>>>>>> does right? Tell you you need to upgrade? >>>>>>>>>>> >>>>>>>>>>> -Rob >>>>>>>>>>> >>>>>>>>>>>> If you want to focus on >>>>>>>>>>>> CVE then setting up on the CI >>>>>>>>>>>> https://sonatype.github.io/ossindex-maven/maven-plugin/ is way >>>>>>> more >>>>>>>>>>>> efficient and accurate (basically when it fails you must act) so >>>>>>>>>>> dependabot >>>>>>>>>>>> is a great reporting tool for managers but not to work on an >>>>>>> everyday >>>>>>>>>>> basis >>>>>>>>>>>> IMHO until it is very finely configure but commons is far to >>>>>>> need so >>>>>>>>> much >>>>>>>>>>>> investment since there already have solutions for everything >>>>>>> needed >>>>>>>>> IMHO. >>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>>>>>>>> https://github.com/rmannibucau> | >>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>>>>>> < >>>>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Le mer. 29 déc. 2021 à 14:39, Rob Tompkins <chtom...@gmail.com> >>>>>>> a >>>>>>>>>>> écrit : >>>>>>>>>>>>> Guys. I think dependabot is our greatest advantage in the work >>>>>>>>> against >>>>>>>>>>>>> security problems. I know she has her failings and is chatty. >>>>>>> But, I >>>>>>>>>>> think >>>>>>>>>>>>> we should open a line of thinking about how best she can help. >>>>>>>>>>>>> >>>>>>>>>>>>> The reason she’s a pain in the ass is that we don’t have enough >>>>>>>>> hands on >>>>>>>>>>>>> the project making it better. I know I would help more, but I >>>>>>> have >>>>>>>>> to >>>>>>>>>>> keep >>>>>>>>>>>>> up with my father who’s a quadriplegic as well as a currently >>>>>>>>> failing >>>>>>>>>>>>> marriage. >>>>>>>>>>>>> >>>>>>>>>>>>> The answer is that we need more hands on the project. I wish I >>>>>>>>> could be >>>>>>>>>>>>> those hands but time and priorities keep me chained. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> -Rob >>>>>>>>>>>>> >>>>>>>>>>>>>> On Dec 29, 2021, at 8:26 AM, Gilles Sadowski < >>>>>>> gillese...@gmail.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl <t...@apache.org> >>>>>>> a >>>>>>>>> écrit >>>>>>>>>>> : >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> Thank you, Phil. This thing is a P.I.T.A. >>>>>>>>>>>>>> In effect, from day one: >>>>>>>>>>>>>> https://markmail.org/message/2vutc4p3b3eqv73f >>>>>>>>>>>>>> >>>>>>>>>>>>>> Basically, the argument is that >>>>>>>>>>>>>> * the (dependabot) feature is too important to be disabled >>>>>>>>>>>>>> * the annoyed people should filter out those mails (which I >>>>>>>>>>>>>> did since no one at the time supported that they be diverted >>>>>>>>>>>>>> to another ML). >>>>>>>>>>>>>> Did anything change since then? >>>>>>>>>>>>>> [Or do we eventually question the general anomaly that code >>>>>>>>>>>>>> discussions have been almost completely off-loaded to GH?] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gilles >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 28.12.2021 um 19:20 schrieb Phil Steitz < >>>>>>>>> phil.ste...@gmail.com>: >>>>>>>>>>>>>>>> I can no longer effectively monitor commits@ due to the spam >>>>>>>>>>>>> generated by this tool. I am afraid my eyeballs aren't the only >>>>>>>>> ones >>>>>>>>>>> going >>>>>>>>>>>>> missing here and that is a problem much more severe than any >>>>>>> value >>>>>>>>>>> provided >>>>>>>>>>>>> by this tool, IMO. >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>> Bye, Thomas >>>>>>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
