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