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