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]> >
