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

[Tomas Hofman]

Reposting to the list.


-------- Forwarded Message --------
Subject: Re: [wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Date: Mon, 2 Sep 2019 17:02:05 +0200
From: Tomas Hofman <thofman at redhat.com>
To: Rostislav Svoboda <rsvoboda at redhat.com>

In general - probably - yes, although I haven't investigated details. I'm 
instead building on top of PME (Project Newcastle) and Maven Versions Plugin, 
so there is code reuse too.


On 02/09/2019 16:24, Rostislav Svoboda wrote:
> 
>> On 2 Sep 2019, at 15:44, Tomas Hofman <thofman at redhat.com 
>> <mailto:thofman at 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 at redhat.com 
>>>> <mailto: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
> 

-- 
Tomas Hofman
Software Engineer, JBoss SET
Red Hat