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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> > >>> 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 < > >>> [email protected]> > >>>>> 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 <[email protected]> > >> 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 <[email protected]> > >>>>>>> > >>>>>> > >>>>>> > >>> > >>> > >>> > >>> -- > >>> Matt Sicker <[email protected]> > >>> > >> > > -- > > Matt Sicker <[email protected]> > >
