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
What are the main differences ?
Rostislav
> On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)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