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

Tomas Hofman thofman at redhat.com
Mon Sep 2 09:44:58 EDT 2019


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 at redhat.com 
>> <mailto:thofman at 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/wildfly-18-minimal.json#L44
>> [3] https://github.com/TomasHofman/wildfly/pulls
>>
>> -- 
>> Tomas Hofman
>> Software Engineer, JBoss SET
>> Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

-- 
Tomas Hofman
Software Engineer, JBoss SET
Red Hat


More information about the wildfly-dev mailing list