You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2019/04/01 00:25:44 UTC
Re: [ALL] Using Dependabot for automatic dependency updates?
It files a PR which kicks off a CI build. I think you can configure it to
automatically merge if the build passes. Otherwise it’s jus another open PR.
On Sun, Mar 31, 2019 at 17:17, Gary Gregory <ga...@gmail.com> wrote:
> Might be worth a try. I take it it only flies PRs if a build passes all
> tests?
>
> Gary
>
> On Mon, Mar 25, 2019, 14:23 Matt Sicker <bo...@gmail.com> wrote:
>
> > I wasn't thinking of automating this fully at any point. The bot does
> > file PRs for each dependency individually. I'm not sure how
> > configurable everything is, but I do like the sound of having multiple
> > dependency management profiles for compatibility testing purposes.
> >
> > On Mon, 25 Mar 2019 at 13:07, Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > This reminds me: What happened to Apache Gump? Didn't it handle this?
> > >
> > > Gary
> > >
> > > On Mon, Mar 25, 2019 at 2:02 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > > There room for automation in this area, but I only seen it as an
> > > > informative step for now. Like the tool saying "I've ran the build
> with
> > > > this change and it's green/red". Today, without this tool, I could
> see
> > a
> > > > tool doing :
> > > > - create a branch for a change and push it, create a PR
> > > > - look at what GitHub/Travis-CI reports
> > > >
> > > > then you, the dev:
> > > >
> > > > - accept/reject the PR
> > > >
> > > > This would only be done one dep change at a time. IOW, only once
> you've
> > > > accepted/rejected a dep change would you move on to the next one.
> > > >
> > > > Gary
> > > >
> > > > On Mon, Mar 25, 2019 at 1:46 PM Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > >> I have mixed feelings. Gary has been manually doing this for quite a
> > > >> while and I have always had concerns - besides driving his commit
> > count
> > > >> artificially through the roof.
> > > >>
> > > >> Managing dependencies really needs to be managed carefully. When we
> > > >> upgrade a dependency that effectively becomes the minimum supported
> > > >> version. In that sense we are upgrading dependencies way too fast.
> At
> > the
> > > >> same time, we need to insure that we don’t have problems with new
> > releases.
> > > >> As such we really need two versions of the parent pom - one that is
> > used
> > > >> for verifying the latest versions of dependencies and one that is
> > used for
> > > >> the release that specifies the minimum supported version (typically
> > this
> > > >> would be expressed as a version range).
> > > >>
> > > >> I’m also concerned because some dependencies upgrade their minimum
> > > >> required JDK version in a minor release. That happened with the
> Flume
> > 1.8
> > > >> release. So we cannot upgrade to that version in the release-2.x
> > branch,
> > > >> although our users can if they want to. We also ran into a problem
> > with
> > > >> SLF4J. The latest release dropped a class that we use. We have
> > modified the
> > > >> code to support the latest releases but we require the last release
> > that
> > > >> had the class to compile.
> > > >>
> > > >> Also, our process has always been to create a Jira for everything,
> > > >> including updating dependency versions, and including them in
> > changes.xml.
> > > >> It looks like this tool doesn’t do either of these things.
> > > >>
> > > >> Ralph
> > > >>
> > > >> > On Mar 25, 2019, at 9:24 AM, Matt Sicker <bo...@gmail.com>
> wrote:
> > > >> >
> > > >> > Hi all,
> > > >> >
> > > >> > Various Jenkins projects have been using Dependabot [1] to
> > > >> > automatically make PRs to update dependencies. We could use this
> for
> > > >> > most of our components it looks like. What do you think about
> > adopting
> > > >> > use of this bot?
> > > >> >
> > > >> > [1]: https://dependabot.com/
> > > >> >
> > > >> > --
> > > >> > Matt Sicker <bo...@gmail.com>
> > > >> >
> > > >>
> > > >>
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [ALL] Using Dependabot for automatic dependency updates?
Posted by Gary Gregory <ga...@gmail.com>.
Well, something with dependencies that need updating would help... but
sure, go for it.
Gary
On Sun, Mar 31, 2019 at 9:06 PM Rob Tompkins <ch...@gmail.com> wrote:
> Do you guys want to try this on something in commons first? We could try
> it on a lesser used component to see how it performs.
>
> -Rob
>
> > On Mar 31, 2019, at 8:25 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > It files a PR which kicks off a CI build. I think you can configure it to
> > automatically merge if the build passes. Otherwise it’s jus another open
> PR.
> >
> > On Sun, Mar 31, 2019 at 17:17, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> Might be worth a try. I take it it only flies PRs if a build passes all
> >> tests?
> >>
> >> Gary
> >>
> >> On Mon, Mar 25, 2019, 14:23 Matt Sicker <bo...@gmail.com> wrote:
> >>
> >>> I wasn't thinking of automating this fully at any point. The bot does
> >>> file PRs for each dependency individually. I'm not sure how
> >>> configurable everything is, but I do like the sound of having multiple
> >>> dependency management profiles for compatibility testing purposes.
> >>>
> >>> On Mon, 25 Mar 2019 at 13:07, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>>
> >>>> This reminds me: What happened to Apache Gump? Didn't it handle this?
> >>>>
> >>>> Gary
> >>>>
> >>>> On Mon, Mar 25, 2019 at 2:02 PM Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>>>
> >>>>> There room for automation in this area, but I only seen it as an
> >>>>> informative step for now. Like the tool saying "I've ran the build
> >> with
> >>>>> this change and it's green/red". Today, without this tool, I could
> >> see
> >>> a
> >>>>> tool doing :
> >>>>> - create a branch for a change and push it, create a PR
> >>>>> - look at what GitHub/Travis-CI reports
> >>>>>
> >>>>> then you, the dev:
> >>>>>
> >>>>> - accept/reject the PR
> >>>>>
> >>>>> This would only be done one dep change at a time. IOW, only once
> >> you've
> >>>>> accepted/rejected a dep change would you move on to the next one.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 1:46 PM Ralph Goers <
> >>> ralph.goers@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I have mixed feelings. Gary has been manually doing this for quite a
> >>>>>> while and I have always had concerns - besides driving his commit
> >>> count
> >>>>>> artificially through the roof.
> >>>>>>
> >>>>>> Managing dependencies really needs to be managed carefully. When we
> >>>>>> upgrade a dependency that effectively becomes the minimum supported
> >>>>>> version. In that sense we are upgrading dependencies way too fast.
> >> At
> >>> the
> >>>>>> same time, we need to insure that we don’t have problems with new
> >>> releases.
> >>>>>> As such we really need two versions of the parent pom - one that is
> >>> used
> >>>>>> for verifying the latest versions of dependencies and one that is
> >>> used for
> >>>>>> the release that specifies the minimum supported version (typically
> >>> this
> >>>>>> would be expressed as a version range).
> >>>>>>
> >>>>>> I’m also concerned because some dependencies upgrade their minimum
> >>>>>> required JDK version in a minor release. That happened with the
> >> Flume
> >>> 1.8
> >>>>>> release. So we cannot upgrade to that version in the release-2.x
> >>> branch,
> >>>>>> although our users can if they want to. We also ran into a problem
> >>> with
> >>>>>> SLF4J. The latest release dropped a class that we use. We have
> >>> modified the
> >>>>>> code to support the latest releases but we require the last release
> >>> that
> >>>>>> had the class to compile.
> >>>>>>
> >>>>>> Also, our process has always been to create a Jira for everything,
> >>>>>> including updating dependency versions, and including them in
> >>> changes.xml.
> >>>>>> It looks like this tool doesn’t do either of these things.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On Mar 25, 2019, at 9:24 AM, Matt Sicker <bo...@gmail.com>
> >> wrote:
> >>>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Various Jenkins projects have been using Dependabot [1] to
> >>>>>>> automatically make PRs to update dependencies. We could use this
> >> for
> >>>>>>> most of our components it looks like. What do you think about
> >>> adopting
> >>>>>>> use of this bot?
> >>>>>>>
> >>>>>>> [1]: https://dependabot.com/
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Matt Sicker <bo...@gmail.com>
> >>>
> >>
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
Re: [ALL] Using Dependabot for automatic dependency updates?
Posted by Rob Tompkins <ch...@gmail.com>.
Do you guys want to try this on something in commons first? We could try it on a lesser used component to see how it performs.
-Rob
> On Mar 31, 2019, at 8:25 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It files a PR which kicks off a CI build. I think you can configure it to
> automatically merge if the build passes. Otherwise it’s jus another open PR.
>
> On Sun, Mar 31, 2019 at 17:17, Gary Gregory <ga...@gmail.com> wrote:
>
>> Might be worth a try. I take it it only flies PRs if a build passes all
>> tests?
>>
>> Gary
>>
>> On Mon, Mar 25, 2019, 14:23 Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I wasn't thinking of automating this fully at any point. The bot does
>>> file PRs for each dependency individually. I'm not sure how
>>> configurable everything is, but I do like the sound of having multiple
>>> dependency management profiles for compatibility testing purposes.
>>>
>>> On Mon, 25 Mar 2019 at 13:07, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> This reminds me: What happened to Apache Gump? Didn't it handle this?
>>>>
>>>> Gary
>>>>
>>>> On Mon, Mar 25, 2019 at 2:02 PM Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>
>>>>> There room for automation in this area, but I only seen it as an
>>>>> informative step for now. Like the tool saying "I've ran the build
>> with
>>>>> this change and it's green/red". Today, without this tool, I could
>> see
>>> a
>>>>> tool doing :
>>>>> - create a branch for a change and push it, create a PR
>>>>> - look at what GitHub/Travis-CI reports
>>>>>
>>>>> then you, the dev:
>>>>>
>>>>> - accept/reject the PR
>>>>>
>>>>> This would only be done one dep change at a time. IOW, only once
>> you've
>>>>> accepted/rejected a dep change would you move on to the next one.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Mon, Mar 25, 2019 at 1:46 PM Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> I have mixed feelings. Gary has been manually doing this for quite a
>>>>>> while and I have always had concerns - besides driving his commit
>>> count
>>>>>> artificially through the roof.
>>>>>>
>>>>>> Managing dependencies really needs to be managed carefully. When we
>>>>>> upgrade a dependency that effectively becomes the minimum supported
>>>>>> version. In that sense we are upgrading dependencies way too fast.
>> At
>>> the
>>>>>> same time, we need to insure that we don’t have problems with new
>>> releases.
>>>>>> As such we really need two versions of the parent pom - one that is
>>> used
>>>>>> for verifying the latest versions of dependencies and one that is
>>> used for
>>>>>> the release that specifies the minimum supported version (typically
>>> this
>>>>>> would be expressed as a version range).
>>>>>>
>>>>>> I’m also concerned because some dependencies upgrade their minimum
>>>>>> required JDK version in a minor release. That happened with the
>> Flume
>>> 1.8
>>>>>> release. So we cannot upgrade to that version in the release-2.x
>>> branch,
>>>>>> although our users can if they want to. We also ran into a problem
>>> with
>>>>>> SLF4J. The latest release dropped a class that we use. We have
>>> modified the
>>>>>> code to support the latest releases but we require the last release
>>> that
>>>>>> had the class to compile.
>>>>>>
>>>>>> Also, our process has always been to create a Jira for everything,
>>>>>> including updating dependency versions, and including them in
>>> changes.xml.
>>>>>> It looks like this tool doesn’t do either of these things.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Mar 25, 2019, at 9:24 AM, Matt Sicker <bo...@gmail.com>
>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Various Jenkins projects have been using Dependabot [1] to
>>>>>>> automatically make PRs to update dependencies. We could use this
>> for
>>>>>>> most of our components it looks like. What do you think about
>>> adopting
>>>>>>> use of this bot?
>>>>>>>
>>>>>>> [1]: https://dependabot.com/
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
> --
> Matt Sicker <bo...@gmail.com>