Re: [wildfly-dev] Automate keeping Wildfly dependencies up-to-date?

On 2 Sep 2019, at 15:44, Tomas Hofman <thofman(a)redhat.com&gt; wrote: Yes, to me the main difference is that dependabot doesn't allow to configure per component "rules" limiting when you want to upgrade.

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 to https://github.com/marketplace/dependabot-preview <https://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 <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