> On 2 Sep 2019, at 15:44, Tomas Hofman <thofman(a)redhat.com > <mailto:thofman@redhat.com>> wrote: > > Yes, to me the main difference is that dependabot doesn't allow to configure > per component "rules" limiting when you want to upgrade. Would it be possible to extend dependabot instead of developing&maintaining own solution? > > E.g. I want to be able to say: for artifacts with G:A "org.picketlink:*", > only upgrade if there's a higher version starting with "2.5.5" and having > qualifier that matches regex "SP-\\d". > > Tomas > > On 02/09/2019 11:45, Rostislav Svoboda wrote: >> This tools sounds similar tohttps://github.com/marketplace/dependabot-preview >> What are the main differences ? >> Rostislav >>> On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)redhat.com >>> <mailto:thofman@redhat.com><mailto:thofman@redhat.com>> wrote: >>> >>> Hello, >>> >>> would the Wildfly team be interested in (or opposed to) receiving component >>> upgrade PRs, which would be created automatically when a new component version >>> is released? (I'm talking about new micro/SP versions, depending on the >>> component, i.e. version that could be reasonably expected to be suitable for >>> consumption, without issues like breaking API changes etc.) >>> >>> I'm working on a tool [1], which is able to provide these PRs. >>> >>> The tool scans given project for dependencies, and then looks at what versions >>> of those dependencies are available in Maven Central and possibly other >>> repositories. I can configure rules for each dependency, that specify what >>> versions should be considered viable for upgrading (e.g. for "org.picketlink:*" >>> we would only offer new "SP" builds in the same micro, for most of the other >>> dependencies we would only offer new micros, and some artifacts would perhaps >>> be blacklisted). Example of this configuration is here [2]. >>> >>> Advantages that I believe could be gained from this: >>> >>> * It would bring us an advantage of having new component micros tested soon in >>> Wildfly, and therefore having more confidence when we need to do the same >>> upgrades in EAP. >>> >>> * It would also help in preventing EAP running ahead of Wildfly in component >>> versions, which happens occasionally. EAP release coordinator usually spots >>> this problem and creates missing PR in Wildfly, but it's a manual check and >>> therefore a small risk remains. >>> >>> * It would ensure Wildfly is consuming latest component fixes. >>> >>> You can review PRs generated last week in my fork of Wildfly [3]. >>> >>> It's a work in progress, I expect the tool and it's configuration would evolve >>> according to experiences we would get from using it... >>> >>> What do you think? >>> >>> [1] https://github.com/TomasHofman/maven-dependency-updater/ >>> [2] >>> https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >>> [3] https://github.com/TomasHofman/wildfly/pulls >>> >>> -- >>> Tomas Hofman >>> Software Engineer, JBoss SET >>> Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat